Web accessibility is the practice of designing and building websites accessible to virtually everyone, regardless of any specific health conditions or impairments. Millions of people around the world require the ability to use websites free from as many barriers as possible.
The goal of a designer or web developer should be to create accessible sites that allow users to enjoy equal access to your site and its content. Digital accessibility aims to leave no one out – whether that’s people with disabilities, people with low vision or other visual impairments (which can include colour blindness), or any other users whose circumstances may affect exactly how they experience your site.
Web accessibility guidelines exist in various forms, the most popular being the “web content accessibility guidelines” by W3C, which we’ll get to below. These guidelines and best practices help web designers and web developers create websites that can accommodate people using assistive technologies such as screen readers.
Web accessibility solutions aim to ensure that all features and functions of a website are accessible to as many people as possible. To say there’s a diverse range of web users would be a serious understatement! Website accessibility guidelines can help us meet the needs of as many of these people as possible.
The WCAG (web content accessibility guidelines) are a set of guidelines aimed at providing a unified set of accessibility standards for web designers and developers. The standards are developed by the Accessibility Guidelines Working Group, which is itself a part of the W3C WAI (World Wide Web Consortium’s Web Accessibility Initiative). Confused? Don’t be – these are all internal working groups of the W3C. From their site: “The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.” [1]
The aim of these groups is to provide guidance to the web community at large by creating and providing standards for the web. The W3C is not here to enforce its standards, but rather to provide guidelines that we, as designers, developers, or organizations, can follow if we choose. Three levels of “conformance” exist within WCAG: A, AA, and AAA. Each standard adds more criteria in order to conform. Many jurisdictions and organizations aim for AA conformance, but the specifics of your situation may vary. WCAG is not the only accepted standard, as some governments have created specific sets of standards for businesses or governmental agencies creating web content in their jurisdictions. When in doubt as to which accessibility standards may apply to you, consider speaking with a lawyer or searching online for any relevant information about web design for accessibility in your area.
While not necessarily difficult, accessible website design requires thought, consideration, time, and effort to implement properly. Web designers and developers must work together to ensure that web accessibility solutions are properly implemented to current standards and best practices. Much like how building codes vary from city to city, state to state, and country to country, web accessibility has no singular, legislated standard. However, there are a number of common accessible design principles that should be used as often as possible.
To create an accessible website, you’ll need to spend time evaluating all of the web pages on your site and testing to ensure that all content and interactive elements work for people with disabilities, be they permanent or temporary disabilities, people with low vision, and anyone else who may make use of assistive technology.
An accessible website makes use of several best practices to help create accessible content. This includes, but is not limited to, web design considerations such as:
<img> tags that describe the purpose of an image for anyone with a visual impairmentBelow, we’ll start getting into some of the specific solutions that exist to address common accessibility problems. Creating accessible websites means starting with accessible design and finishing with an accessible development process. It should be a holistic process involving all members of a web development team or agency. There are evaluation tools which we’ll also mention that can help identify accessibility problems and pose solutions.
While some users will browse the web with a screen reader, not all persons with visual impairments will, and this should be a consideration when creating colour contrast in your designs, especially as it pertains to text.
Our advice? Use a contrast checking tool such as https://colourcontrast.cc/. This allows you to plug in your desired foreground and background colors, giving you a “pass/fail” result on your colour contrast based on WCAG AA and AAA conformance parameters. Aim for a minimum contrast ratio of 4.5:1 if developing for AA conformance.
Ensuring that your text is sized correctly (or easily resizable via browser zoom tools without breaking the page layout) is fundamental to good web accessibility.
This may not always be possible, but where you can, avoid having text in your images. Screen readers (and search engines, for that matter) currently don’t read text in images. If you have important information in an image and it’s not possible to leave it out, you should try to add a caption, detailed alt tag, or another semantically appropriate tag to convey that same information again in text format.
Screen readers will literally read aloud the text on a web page – they create an audio description of many elements and include metadata attributes such as image alt tags or link titles.
Because of this, it’s imperative that you properly tag all images using the alt text feature. Use descriptive terms such as “a photo of two people using a tablet to watch a movie” or “a surfer riding a large wave while the sun rises in the background”.
One important caveat: we’d suggest ignoring alt tags for purely decorative images. Some SEO tools or automated checkers may insist on alt tags being present for every image on a web page. At first glance, these tools may report these as accessibility violations and you’d be tempted to correct them. However, that’s not always the best path forward.
According to WCAG, “Decorative images don’t add information to the content of a page … in these cases, a null (empty) alt text should be provided (alt=””) so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text.” [2]
In other words, don’t feel the need to make screen readers describe every single image on your site if they don’t represent meaningful content. Use your judgement, but remember that useless alt text may end up making your site harder to follow as it’s parsed and read aloud.
Really, this tip should be considered for all users of your site. Overly long, run-on sentences, or content full of technical jargon or difficult terms can quickly become overwhelming. This is especially true in cases where assistive technologies are being used – imagine how difficult it could be to follow along.
As with alt text for images, you’ll need to use your judgement. The goal should ultimately be to write clear, concise content using only as much complexity as is needed to meet your goal.
You may find yourself wondering, “what is semantic HTML?” and you wouldn’t be the first developer to ask. Semantic HTML is, in its simplest definition, the use of HTML tags that are appropriate to the content within them. Simple examples would be using a <p> tag when writing a paragraph and using a <nav> element when defining a set of navigation links.
Semantic HTML literally means using HTML that refers to the meaning of the content inside of it. An <h1> tag should be the primary header on a web page. An <article> tag should wrap content that belongs on its own. The <article> should then be comprised of other semantic elements like headers and paragraphs.
Here is a good example of when you’re not using semantic HTML. Let’s say you create your main page header using a <span> tag. Yes, visually, you can use CSS to make the <span> element the largest and most bold item on the page, but that <span> element does nothing to tell screen readers that it is currently parsing a header. This is why <h1> tags exist and should be used instead – that would correct your snippet and make for semantic HTML.
Sometimes you need to use non-semantic tags like <div> and <span>. But, where possible, use semantic HTML so your code can help describe the structure and layout of the content on your page.
Even though the purpose of your form fields and icons may seem completely intuitive, it may not be the case with, for example, blind users using a screen reader. Ensuring that your form fields have proper <label> elements means that screen readers can give an audio description of the purpose of each field the user is interacting with.
If <label> text breaks the visual aesthetic of your site or is otherwise unnecessary for sighted users, consider moving your labels off-screen using CSS. One important note: Screen readers will not typically read elements that have display: none; or visibility: hidden; properties in their CSS definitions. For this reason, it is recommended that you use a solution such as position: absolute; and set, for example, a left: -10000px; property. If used on a <label> element, this will move it far off-screen for regular users. However, screen readers will still read forms labeled like this if they’ve only been moved as they do not care about items with absolute positioning – they will evaluate their position on the DOM (Document Object Model).
Your site should be, where possible, navigable using a keyboard. Keyboard accessibility is important to many people, including those with limited fine motor control for whom a mouse may not be a good input device.
Using semantic HTML should help with keyboard navigability by default, as semantic HTML elements have better native support from web browsers for keyboard navigation. For example, using a <button> element instead of a <div> element paired with a JavaScript click handler should ensure that your buttons are easy to focus on and interact with using a keyboard.
From a CSS perspective, you may also want to add high contrast colour outlines for :focus states. This can give a clearer indication to low vision users which element they are currently focused on.
You can easily test the keyboard navigability of your site. Simply set aside your mouse and try browsing your web pages using your keyboard. Use the tab key and arrow keys for navigation and things like the spacebar and enter keys for interaction with focused elements on your site.
Windows and Mac both come with built-in assistive technologies such as screen readers. Others are easily obtainable via Google search and are highly-rated.
In addition to the keyboard testing we suggested above, try using a screen reader. Does anything get missed? Is it read in the proper order? Do all of your non-decorative images get described?
There are also some readily available accessibility auditing tools such as the EqualWeb Accessibility Checker extension for Google Chrome, currently available for free.
At the end of the day, there’s certainly one easy way to determine if you’ve built an accessible website – test it!
Accessible Rich Internet Applications, otherwise known as ARIA, is a technology that was created to help you, the developer, code an accessible website. However, many developers have mistakenly used ARIA all over their site when the use of semantic HTML would be preferable.
This quote from the W3C website talks about “Rule #1” of ARIA use:
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Under what circumstances may this not be possible?
- If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
- If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
- If the feature is not currently available in HTML.
Still want to see an example of ARIA use? Here, we’re using ARIA to describe an element you can toggle (such as mobile menu icon for navigation on portable devices or small screens) which will benefit screen readers. Check out this first code snippet:
<a href="#" id="mobile-menu-toggle">
<i class="fas fa-bars"></i>
</a>This is a fairly standard way of implementing a mobile menu icon using FontAwesome. Typically, you’d have some JavaScript written to handle the showing/hiding of your <nav> items when this icon is ‘clicked’.
The problem is that, contextually, this snippet means nothing to a screen reader. Here’s where ARIA can help:
<a href="#" id="mobile-menu-toggle" aria-label="Open the mobile menu">
<i class="fas fa-bars" aria-hidden="true"></i>
</a>The aria-label attribute gives screen readers a label to announce to the user. Similarly, the aria-hidden="true" attribute on the hamburger/bars icon tells the screen reader to ignore it –- we don’t need the icon to be identified to screen reader users because they’ll interact with the <a> tag.
This is just one example, and there are many ways to replace ARIA with better use of semantic HTML. Of course, it happens to the best of us as we learn of new and better techniques that we didn’t do things semantically. In these cases, ARIA may be the preferred solution for retrofitting accessibility into a past project.
Just remember: “No ARIA is better than bad ARIA“. This is straight from the people who set the standard!
When it comes time to develop, we currently like these two Google Chrome extensions:
Website accessibility is easier than ever to develop, test, and report on. That being said, it’s an endeavour that needs to be factored into a project, as the additional time it takes to develop and test your website accessibility may be significant.
Overall, creating accessible websites is an incredibly important job that should become a part of all web development projects moving forward. An accessible website is an inclusive website, and that should be a priority for any website owner.
Accessibility requirements may vary, but if your jurisdiction has no specific legal requirements, sticking to the WCAG specifications will certainly go a long way.
Want to get a quote on your project? Get started by contacting us now!