A few months back, Aaron wrote about the high-level aspects of Accessibility-First Programming, its importance, and specific strategies and tools for applying it within your software development process. It included insights and suggestions for Color and Contrast, Focus Management, the use of ARIA tags and attributes, and testing strategies and tools – all of which are important things to consider.
In this post, we’re going to dig in a little deeper on three of those topics that I used on my last project: ARIA, the WCAG and what is needed for compliance, and some design principles of accessible design. We’ll include insights and further reading on relevant topics to help you better understand how to implement accessibility-first programming in your own development.
ARIA – Accessible Rich Internet Applications
Accessible Rich Internet Applications (ARIA) was developed by the Web Accessibility Initiative (WAI), as a part of the World Wide Web Consortium (W3C). It is a set of markup extensions that provide additional description and meaning to the elements within your site or application, in order to enhance accessibility for users with visual, hearing, motor, and cognitive disabilities or impairments.
Each of these categories requires certain types of changes in the way you design web content, and these changes benefit almost everyone, not just those with disabilities. Check out this Intro for Web Accessibility.
According to Accessible Metrics, not all websites must use ARIA attributes to be considered accessible. ARIA attributes are intended to be used just in cases where part of a site is difficult to use or unclear with a screen reader or other assistive technology.
In truth, most of the elements you use in modern websites today are already accessible and don’t need additional ARIA attributes. However, if you have tested your site and it isn’t accessible, ARIA may offer solutions to fix it.
There are many diverse ways that content and information can be displayed online. Therefore, ARIA must be flexible with the ability to solve a variety of accessibility issues. The issues are divided into the following three subsections: states, properties, and roles. For more detailed information about ARIA functions and organization, see the WAI-ARIA 1.1 document.
WCAG and Compliance
So how do you know if your site is accessible or not?
The W3C’s web accessibility initiative put together a set of Web Content Accessibility Guidelines known as WCAG, that a site can be assessed against. The guidelines are made up of several testable success criteria, which gives clear objectives to work toward.
Levels Of Compliance
There are three “levels” of compliance in the guidelines to work toward. Every one of the accessibility success criteria/techniques are assisted a particular level. Level A, which is the lowest, AA, and AAA, the highest.
- To be level A compliant, a site must meet every one of the level A criteria.
- To be level AA compliant, a site must meet all level A and level AA criteria. Typically, when you make a site accessible, you aim to meet the criteria for level AA.
- The criteria for AAA can be complicated and, in some cases, impossible to meet depending on your site. Though, of course, you should try to meet AAA if you can.
There is a handy quick reference is available at https://www.w3.org/WAI/WCAG21/quickref/ which goes through all of the success criteria from W3. The table of contents is broken down into the four principles, and then their success criteria. You can then click on a success criterion and it will give you a short description, the level of compliance, and some links for more information, and examples of what to do and not to do. It’s easy to work through and it contains a lot of useful examples for implementing changes.
I’ve summed up some of the information I found particularly useful on the Quick Reference as follows, but so many more suggestions are again listed https://www.w3.org/WAI/WCAG21/quickref/.
At its core, the WCAG criteria are grouped into four principles:
Content should be Perceivable. This means that users must be able to identify the information being presented (it can’t be invisible to all of their senses).
- Provide text alternatives for non-text content.
- Provide captions and other alternatives for multimedia.
- Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
- Make it easier for users to see and hear content.
It should be Operable with a keyboard and easy to navigate. This means that users must be able to control the interface (the interface cannot require interaction that a user cannot perform).
- Make all functionality available from a keyboard.
- Give users enough time to read and use the content.
- Do not use content that causes seizures or physical reactions.
- Help users navigate and find content.
- Make it easier to use inputs other than keyboard.
Sites should be Understandable and behave in predictable ways, helping the user to avoid mistakes. This means that users must be able to comprehend the information, as well as the operation of the user interface (the content or operation cannot be beyond their understanding).
- Make text readable and understandable.
- Make content appear and operate in predictable ways.
- Help users avoid and correct mistakes.
Sites should be Robust and well structured, maximizing compatibility with current and future technologies, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible).
- Maximize compatibility with current and future user tools.
In addition to the WCAG, there is also Section 508 of the Rehabilitation Act of 1973, which is another set of accessibility guidelines defined by the US government. Any software used by federal agencies must comply with it. There’s just a single level of compliance, but most of the guidelines are very similar to the WCAG.
Realistically, all you can do is take as many steps as possible to make your sites more accessible to an acceptable standard. It’s not possible to claim that a site’s 100% accessible just because it meets the WCAG. The goal is to use a variety of techniques to ensure you’re doing everything you can to improve overall accessibility.
Key Design Principles
Below I have listed some key principles of accessible design that I found useful from the WebAIM site. Most accessibility principles can be implemented very easily behind the scenes and will not impact the overall “look and feel” of your website.
Design to standards – HTML compliant and accessible pages are more robust and provide better search engine optimization. Cascading Style Sheets (CSS) allow you to separate page content from how that content is presented visually. This provides more flexibility and accessibility of your content.
Provide appropriate alternative text – Alternative text provides a text alternative for non-text content in web pages (like images). It is especially helpful for people who are blind and rely on a screen reader to have the content of the website read to them. Alternative text can be presented within the
alt attribute of the
img element or even within the context or surroundings of the image itself.
Provide appropriate document structure – Headings, lists, and other structural elements provide meaning and structure to web pages. They can also facilitate keyboard navigation within the page.
Provide headers for data tables – Tables are used online for layout and to organize data. Tables that are used to organize tabular data should have appropriate table headers (the
th element). Data cells should be associated with their appropriate headers, making it easier for screen reader users to navigate and understand the data table.
Ensure users can complete and submit all forms – Ensure that every form element (text field, checkbox, dropdown list, etc.) has a label and make sure that label is associated with the correct form element using the
label element. Also make sure the user can submit the form and recover from any errors, such as the failure to fill in all required fields.
Ensure links make sense out of context – Every link should make sense if the link text is read by itself. Screen reader users may choose to read only the links on a web page. Certain phrases like “click here” and “more” must be avoided.
Caption and/or provide transcripts for media – Videos and live audio must have captions and a transcript. With archived audio, a transcription may be enough.
Allow users to skip repetitive elements on the page – You should provide a method that allows users to skip navigation or other elements that repeat on every page. This is usually accomplished by providing a “Skip to Main Content,” or “Skip Navigation” link at the top of the page which jumps to the main content of the page.
Do not rely on color alone to convey meaning – The use of color can enhance comprehension, but you should avoid the use of color alone to convey information. That information may not be available to a person who is colorblind and will be unavailable to screen reader users.
Make sure content is clearly written and easy to read – There are many ways to make your content easier to understand. Write clearly, use clear fonts, and use headings and lists appropriately. Also ensure your content is structured logically, written with correct grammar and punctuation, and using active voice.
Ensure accessibility of non-HTML content – including PDF files, Microsoft Word documents, PowerPoint presentations, and Adobe Flash content. In addition to all the other web-specific principles listed here, PDF documents and other non-HTML content must also be as accessible as possible. If you cannot make it accessible, consider using HTML instead or, at the very least, provide an accessible alternative. PDF documents should also include a series of tags to make it more accessible. A tagged PDF file looks the same, but it is almost always more accessible to a person using a screen reader.
On your next project, make sure to keep Accessibility-First Programming in mind from the beginning. Following the guidelines and design principles listed above can get you a long way towards a more accessible site and better user experience. Remember to use ARIA tags and attributes only as needed. Also, test out your site with WCAG in mind, using the various tools, extensions, and screen readers that are available.
A site that is perceivable, operable, understandable, and robust will ensure you’re doing everything you can to improve overall accessibility.