Three Web Accessibility Wins for Web Developers
by Will Ginsberg, Agile Software Engineer
Reaching WCAG A, AA, or even AAA compliance on your website is far from a simple task. But that doesn’t mean you can’t start making a huge difference for the accessibility of your site or web app today. Here’s 3 quick wins to make that happen.
1. Add a skip link
Navigation bars and other content that is repeated across pages can easily pose an unnecessary hurdle to some users. For example, when attempting to read an article on a news website, a user who relies on screen reading technology may have to listen through dozens of navigation links before reaching the main content of the article. As recommended by WCAG level A success criteria 2.4.1 Bypass Blocks, a skip link can be added to the page to allow the user to navigate straight to the main content. Is that link going to be unsightly? Not to worry, we can use CSS to hide it for mouse users.
Here’s an example of putting it all together:
Taking it a step further
Consider mobile devices
How might your users navigate with assistive technology on mobile devices? Surprising or not, implementing a skip link that provides a great experience on mobile browsers presents its own challenges. Check out Axess Lab’s great article, “Your skip links are broken” for more information.
Consider alternatives to the skip link
Skip links may not be a comprehensive solution for allowing all users to easily navigate content on your web pages. For strategies beyond the skip link check out WebAIM’s “Skip Navigation” Links article.
2. Use semantic HTML for clickable elements
Various HTML elements convey information (semantics) beyond their visual presentation to accessible technologies such as screen readers. One HTML element that can increase accessibility is the <button>. When the HTML button element is properly used it provides an indication to users that an action can be completed by clicking on it. Clicking can of course be completed with a standard mouse, or with any number of assistive technologies, such as a voice controlled web browser.
Div tags are often used incorrectly in place of an anchor or button element, which provides no indication that the element can be clicked to complete an action. This can be considered a failure to meet WCAG level A success criteria for keyboard operability 2.1.1.
Taking it a step further
Make it pretty
One pitfall of using the HTML button element is that it does add its own default styling, which can be inconsistent with the styling of the rest of the page. This is easy to overcome by overriding default styling as needed. For example, in the above codepen, the semantic button demonstrates the default browser button styling and a button with the default styling overridden.
Use anchor tags too
Another element to which this thinking applies is the anchor tag <a>. While other elements are occasionally used to provide a link to another page (I’m looking at you, single page apps), the anchor tag provides much greater accessibility for users. Like we saw in the skip link example, an anchor tag can even be used to provide navigation to sections within the same page.
3. Support keyboard navigation by showing focus outlines
While the majority of users navigate the web with a touchscreen or mouse, this is not universally the case. For example, people with hand tremors may opt to use a keyboard instead to click through a web page. To make a web page accessible to these users requires displaying visual outlines around each interactive element in the page. For example, the user can repeatedly press the tab key and will see each button on that web page highlighted in sequence. This functionality is actually supported ubiquitously across web browsers, however, it’s often overridden by authors for aesthetic purposes with code similar to the following CSS:
// Overriding the browser’s default accessible focus outlines for all elements in the page.
// Please don’t do this
*:focus {outline:0!important}Luckily, in this case, we can have some cake and eat it too by removing focus outlines only after we have detected that a mouse is being used. I like to use outline.js as a starting point. You can import it as a package if you’d like, or copy the (short) main script and adapt it as needed.
Taking it a step further
Consider why everyone can benefit from focus outlines
Preserving the browser default focus outlines is one important step towards meeting the WCAG level A success criteria for keyboard operability 2.1.1. It is also worth noting that WCAG level AA also explicitly includes a success criteria for focus visibility: 2.4.7. The reason is that visible focus also benefits users with attention and short term memory limitations, or limitations in executive processes, since these outlines give an extra visual indication of what is going on in the page.
I hope all you web developers out there can start to implement these three quick wins in your projects to start reaching compliance with the WCAG accessibility guidelines. Most importantly though, this should open the door to thinking about web accessibility more deeply. Building web content that is easy to understand and interact with provides the best possible experience and helps you to reach the largest audience of users (and it’s the right thing to do).
For more information on web accessibility for developers, click here to speak to one of our experts.
Will is an Agile Software Engineer at TribalScale where he works with a variety of web and internet technologies. He is passionate about learning and teaching others how to improve accessibility. You can usually find him riding his bike up and down Toronto’s waterfront or watching bad reality TV.
TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!
