The Intimidation Barrier Strikes Back

We have lived this before: In 1989, the usability guru, Jakob Nielsen, stunned the usability community by presenting the Discount Usability Engineering approach. Nielsen noticed that the recommended usability methods, some invented by him, are rarely used in real-life projects. Among the reasons were the perceived cost of the techniques, them being time-consuming, and their complexity. Nielsen called it “the intimidation barrier” and lowered the bar to a more moderate approach on the premise that some usability is better than none.

Back to the present day. Web accessibility relies primarily on the standards of semantic HTML and the Web Accessibility Initiative’s Accessible Rich Internet Applications (WAI-ARIA) for its implementation and the Web Content Accessibility Guidelines (WCAG) for its verification. Many software developers are unfamiliar with the proper use of these standards, since those are not sufficiently emphasized in their education and training. Combined with the perceived complexity of the standards, developers have formidable hurdles to start practicing accessibility. In their words:

• It’s hard to ensure everything is accessible
• What accessibility tools to use and how to effectively use them
• Difficult understanding standards like WCAG
• I’m not sure where and how to use ARIA
• Difficult finding a guide for beginners

The so-called intimidation barrier seemed to strike back, and one solution might be to start with a lower bar.

Setting Your Accessibility Bar

The bar analogy is taken from athletics. No athlete starts by setting the bar on the world record. Similarly, in the absence of an accessibility expert, it wouldn’t be practical for a developer unfamiliar with accessibility to set the bar on full compliance with the WCAG standard. The bar can be set to a level that can be reached now and iteratively exceeded later. Because, well, addressing some accessibility issues is better than none.

Examples of accessibility bars could be:

• Semantic HTML
• Low hanging fruits
• Keyboard accessibility
• Graphics and multimedia
• Forms
• Common ARIA cases

We use the browser extensions axe DevTools (Chrome, Firefox, Edge) and keyboard simulator taba11y (Chrome) for testing. Some issues can already be identified in your source code with axe linter. And also, get familiar with the accessibility tree, e.g. on Chrome DevTools. The accessibility tree is used by assistive technologies such as screen readers, so you can easily see how UI elements are communicated to screen readers. Next, let’s dive into the implementation and verification of each accessibility bar.

Semantic HTML

Semantics are about meaning. Semantic HTML refers to the elements that convey meaning, both to humans and to systems. For instance, <nav>, <h1>, <button> and <input> have their own meanings, whereas <div> and <span> are generic containers with no built-in meaning. Semantic HTML is fundamental to accessibility; semantic elements are accessible by default, resulting in a more robust, concise and readable code and systems that are more performant. So, this is the ultimate starting level for accessibility. 

Did you know that there are 113 HTML elements? About 100 of them have semantics. Check them out, and you might find ones you didn’t know about. Make sure you use elements based on their purpose. In our accessibility audits, we commonly find issues with the markup of page regions, headings, content structure, buttons and icon buttons, links, images as links, form fields, and custom elements. Getting these properly marked up is a huge accessibility leap.

Testing for semantic markup requires both tools and manual tests. Some issues can be found by axe DevTools, such as the absence of <main> tag, the illogical organization of headings, and invalid markups. With taba11y, you can quickly find elements that should be focusable but do not receive focus. Many other issues, such as the absence of certain elements or the incorrect markup of elements, are not identifiable by automatic checkers. So make yourself a habit of scanning the DOM and tabbing through the UI with a keyboard.

Low Hanging Fruits

These are the most commonly found Web accessibility issues based on the WebAIM Million annual analysis. Issues like low contrast text, missing alternative text for images, missing input labels, and empty links and buttons are super easy to detect and fix, so they are known as accessibility’s “low hanging fruits”. Being easy to detect does not mean that the issues are the most critical, but as WebAIM affirms “addressing just these few types of issues would significantly improve accessibility across the web”. 

You can easily pick these ‘fruits’ with axe DevTools. Alternatively, follow the excellent guidelines by Hidde de Vries on detecting and fixing these issues. And since you already scanned the page with axe, go the extra mile - check out the other issues found and try fixing them; the tool and its linked online resources are one of the best hands-on approaches to learn accessibility.

Keyboard accessibility

Many people cannot or do not use a mouse due to limiting conditions, system requirements, or personal preferences. Instead, they rely on a linear keyboard-only interaction, mainly using the tab key for moving through elements, arrow keys for scrolling and moving through options, as well as the spacebar and enter keys to take action. To facilitate effective keyboard-only interaction, accessibility requirements include:

• Comparable interaction - everything that can be done with a mouse should also be accessible by keyboard
• Focus indication - clear visual indication of the focused element
• Navigation order - meaningful tab order, commonly based on the page flow
• Skip links - a mechanism to bypass repeated content, such as navigation items
• No keyboard trap - focus can be moved away from any component by keyboard
• Avoid custom single-key shortcuts - problematic for accidental key hits 

Start by checking WebAIM’s excellent guidelines on implementing and testing keyboard accessibility. In addition, taba11y renders a quick and helpful overview of focusable elements and the tab order. And axe DevTools has guided keyboard testing as part of its premium package (nope, no affiliation). Yet, the best keyboard testing approach is manual; check that you meet the requirements mentioned above by using your system with keyboard-only interaction.

Graphics and Multimedia

Images, video, and audio greatly enrich the online experience. So if not accessible, they significantly deteriorate the experience and can even be a showstopper. The W3 Web Accessibility Initiative (WAI) has excellent guides on providing alternative texts to images and making audio and video media accessible. The Bureau of Internet Accessibility compiled a concise checklist for creating accessible videos. If you use icons, check out Chris Coyier’s accessible SVG icons, accessibility of Font Awesome icons, and Sara Soueidan’s accessible icon buttons. 

The accessibility of images and multimedia can be partly tested with axe DevTools for issues like missing alternative texts or video captions. But verifying that texts and captions (also transcripts, and audio descriptions) are meaningful and provide an equivalent experience to the visual and audial experience requires manual testing. 

Forms

Forms allow user input and are used in almost every system for various purposes, such as logging in, searching, purchasing, registering, commenting, filling out a questionnaire, and setting preferences. Non-accessible forms prevent certain users from doing all these. The W3 Web Accessibility Initiative (WAI) has an excellent tutorial on the essentials of creating accessible forms, including guidelines for labeling and grouping fields, form instructions and validation, and error handling. Follow these, and you are off to a great start with another accessibility bar.

Testing forms with automatic checkers is rather limited, primarily detecting missing field labels and incorrect markups. So test manually by using the form with keyboard-only, checking that tab order is meaningful, focus is clearly indicated, and form states —validation, success, error— are handled as expected. Testing with a screen reader, or checking the accessibility tree, would further detect meaningful information that is missing or only visually presented, such as field instructions, required state and error state. 

Common ARIA cases

If semantic HTML is accessible by default, why do we need ARIA (short for Accessible Rich Internet Applications)? As the full name implies, ARIA enriches applications, especially for assistive technologies, in situations where the semantics are not available in HTML. For instance, tabs are a common design pattern with no semantic element; so we use ARIA roles to repurpose existing elements as ‘tablist,’ ‘tab,’ and ‘tabpanel,’ and make the pattern properly communicated to screen reader users. Another typical pattern is a button that contains only an icon with no text. Enriching the button element with the ‘aria-label’ attribute ensures that screen reader users understand the button’s purpose.

Always start with semantic HTML. Use ARIA only when the semantic is not sufficient. Check out W3 WAI guidelines on how to use ARIA in common design patterns and components, MDN’s examples of common WAI-ARIA implementations, and Smashing magazine’s list of accessible components. Didn’t find what you needed? Search for ‘accessible [pattern name]’, most likely, someone already implemented it. Last, check Deque’s common ARIA mistakes, because incorrect ARIA roles, attributes, or states can create more confusion than value for non-visual users.

Testing ARIA requires a screen reader or at least checking the accessibility tree for elements that use ARIA. And that’s it. Implementing the common ARIA cases is a huge milestone toward full compliance with accessibility guidelines.

Wrap Up

If you face challenges starting with accessibility, consider lowering the bar to an attainable goal. For instance, semantic HTML or the low hanging fruits that are easy to detect and fix. When these become a routine practice, iteratively raise the bar by adding more accessibility considerations. Becoming an expert in something (or a champion athlete) requires starting from somewhere. How about starting with accessibility today and raising the bar as you go? 

Lastly, I would be glad to hear about your experience in case you use this approach. 😊

Feel free to contact me via email eyal.eshet@vincit.fi or by sending me a message via my social media accounts in LinkedIn and Twitter.