9 tips to get bare minimum of web accessibility

Making an accessible site means making it for ‘almost’ everyone. And the good news is that its very easy to make an acceptably accessible site. Let me tell you how:

1) Keyboard accessible

  • All the interactive elements of your page e.g. text boxes, buttons etc should be accessible by keyboard. That means you should be able to bring focus on them by using Tab and Shift+Tab keys.
  • Most of the interactive elements are keyboard accessible by default, i.e. browser takes care of making them keyboard ‘focus-able’.
  • Non interactive elements like div, span and images are not keyboard accessibly by default. This is fine because users don’t generally need to interact with them.

2) Tab-order

  • The order in which elements get focus is called tab-order. Developers need to take care that the interactive elements have logical tab-order. Tab order should follow the natural reading sequence i.e. top to bottom and right to left (for an RTL type language). If your tab focus is jumping around the page unpredictably then its not going to be great experience for the users.
  • Tab-order mainly depends on the dom-order, i.e. the way you have written your html. Any element which is ahead in the dom tree automatically goes ahead in the tab-order.
  • Sometimes people use css to make the element appear in an order which is different form dom-order. Example:
<a href="#" style="float:right;">Right aligned link</a> 
<a href="#">Link 1</a>
<a href="#">Link 2</a>
  • In above example first the focus will move to right and then it will come to left because right aligned link appears above in dom. That’s not great because you would generally expect leftmost link to be focussed first. This is how you can solve it:
<a href="#">Link 1</a> 
<a href="#">Link 2</a>
<a href="#" style="float:right;">Right aligned link</a>

3) tabindex

  • To make a non interactive element focusable you can give it tabindex = 0 attribute. Example: <div id=”myDiv” tabindex = 0>Dummy text</div>. This not only makes the element tab accessible but also makes it programmatically focusable. That means you can call .focus() on that element.
  • tabindex = -1 will take out any interactive element from tab-order. That means you can not access it through keyboard. This is particularly useful when you want to make few links/buttons inaccessible when they are behind an overlay or transitioned out of display (e.g. hamburger menus)
  • Positive tabindex value makes the element tab accessible and also puts the element ahead in tab-order based on the value of the attribute. But positive tabindex values are considered anti-pattern becuase it may get very confusing more than one elements have positive tabindex values. So, don’t use positive tabindex.

4) Use native elements

  • As far as possible please use native elements for any specific purpose. That means, for example, if you need a button then just use button tag rather than making a button using divs or spans.
  • Native interactive elements like buttons, selectboxes etc have many built in accessibility features which you might miss if you are creating your own.

5) Guideline for custom elements

  • If you must create a custom element then make sure that you go through the wai-aria best practices guide. Link: https://www.w3.org/TR/wai-aria-practices-1.1/
  • You don’t have to go through the whole document. You can only check guidelines for the element you are going to make
  • For example, if you are making a custom checkbox then make sure to follow the guidelines here: https://www.w3.org/TR/wai-aria-practices-1.1/#checkbox
  • These guidelines tell you how the keyboard interactions should be for any element. It also has links to demo and code examples for our help.

6) Screen readers

  • Many users with visual impairment rely on assistive tools like screen readers to get information on the page and to interact with page
  • Always use alt attribute for images. Screen readers would read out the alt text for its users who have difficulty in seeing the image.
  • Use proper heading tags <h1>, <h2>, <h3> etc for headings, because screen readers allow users to navigate within the content of page using headings.
  • Make efficient use of semantic tags like <header>, <footer>, <section>, <nav> etc because screen readers allow users to navigate within the content of page using these tags.
  • Screen readers need to identify the interactive elements correctly so it can ask users to interact with them. For example, if you have created a button using <button> tag then screen reader will call it out as button. But if your button is something like this <div class=”fancy-button”>Submit</div> then screen reader will call it a “group” because div is grouping element, and user would not understand that they are supposed to interact with that element.

7) Labels and aria attributes

  • Any code written in html not only has a visual representation but also has a semantical representation called accessibility tree. Accessibility tree is used by assistive tools like screen readers to inform the user about the accessibility properties like type, name, state and value of the element. The values of these accessibility properties are computed by browser based on the information provided in html code.
  • In above example name is computed by the <label> tag. Make use of label tag wherever applicable.
  • Use aria-label attribute to ensure that element has a name. Suppose you have a save button which does not have a text content, then browser will not be able to compute its name. We can mention aria-label attribute to help browser compute its name.
  • Similarly use different aria attributes like role, aria-labelledby, aria-expanded, aria-checked etc to help browser compute accessibility properties. Refer https://www.w3.org/TR/wai-aria-practices-1.1/ to know relevant aria attributes for any type of control.

8) Use tools

  • aXe is an amazing tool to identify the accessibility gaps in your page. It is a chrome extension. Install it and use through chrome dev tools to analyse the accessibility of the page.
  • Use aXe to analyse colour contrast in your page. A bad colour contrast ratio will make it difficult for few users to read the text. aXe can point out the regions of your page where the contrast does not match the WCAG guidelines.
  • Chrome has an experimental accessibility inspector in dev tools. Go to setting -> experiments in chrome dev tools to enable it. This tool helps by letting you know the computed accessibility properties
  • If you want to automate the accessibility audit in your project, you can use axe-core. It is a node module which you can include in your build process.

9) Libraries and polyfills

  • inert.js is a very useful library which helps you make a part of your page tab inaccessible. This is particularly useful when you want to make few links/buttons inaccessible when they are behind an overlay or transitioned out of display (e.g. hamburger menus)
  • Focus-ring is the outline which gets displayed around the control when it receives focus. At times, especially with buttons, these focus rings are not very aesthetically pleasant so developers tend to disable it in css (outline:none). Mouse users wouldn’t face any issues because of this but keyboard users find it problematic because can’t figure out whether the control has focus or not. Ideally focus ring should be visible to keyboard user even if it is invisible for mouse user. https://github.com/WICG/focus-ring is an awesome library which helps you achieve that.

Thanks for reading!

Thanks Rob Dodson for a11ycasts.

Also in my blog http://dotjsfile.blogspot.in/2017/05/tips-for-bare-minimum-of-accessibility.html