Accessibility Best Practices

Always consider accessibility as a general practice. Never consider it as a optional feature that we should consider to add in our website, instead it is a trend, mindset and responsibility of developers. Best practices for accessibility that we are going to discuss here are best practices overall. I am going to list down few important points that I learned after working on accessibility and how it inspired me to develop a VSCode extension for the component library that we use. Its not that accessibility is only for disabled person. Even person without disability may want to access your site with keyboard, read transcript instead of watching video, and what not. You are missing on large set of audience by not making it accessible.

1. Use proper HTML tags: Most of the problem that we had was due to improper usage of HTML tags. button that we see on screen is actually a styled div. Due to this, new button will never receive a focus. So, either use button tag or under some circumstances if you are compelled to use div, do not forgot to pass tabIndex, onKeyDown and proper aria-label if required. Similarly use proper heading levels. This will help the screen reader user to skip through the content and find the important things more quickly. To follow this, I added the rule in VSCode extension that yells if you only pass onClick handler to some div. and suggest you to pass onKeyDown too or replace it with button

2. Initial focus If you use any kind of surface component like Modal, Tooltip, Popover, Portal. Then as soon as it opens, focus should directly transfer to the first interactive element and focus should be trapped in that component. To follow this, added the info in extension that informs you to verify this behavior whenever we use any such component.

3. Use flex box Use float styles under exceptional condition only. In most of the cases flex styles are more than enough. floating styles changes tab order. Consider the following code and how it is rendered -

   1<Box>
   2  <Button className="float-right">First in DOM</Button>
   3  <Button className="float-right mr-2">Second in DOM</Button>
   4</Box>

   FirstSecond

   If you tab through above buttons, you will find that logical tab order is different from visual. Why? Because right most button appeared first in our code and thus DOM, but we dragged it to the right with float styles. And focus order is determined by the structure of the DOM unless higher tab indices are not present in our code.

   Now consider the same example with flex version

   1<Box className="flex justify-end">
   2  <Button className="mr-2">First in DOM</Button>
   3  <Button>Second in DOM</Button>
   4</Box>

   FirstSecond

   and 💥💥 it works as expected with correct focus order. To follow this, added one more rule in extension that gives warning on using float styles.

4. Proper encapsulation Maintain proper encapsulation of global components by not using the styles like margin, padding, of course float, etc on root node. Even if you plan to use it at specific place only, let parent component which will be using this to handle these styles. In past few days, I am working with one such navbar component to fix the accessibility issue. Component is very simple. It takes leftActions and rightActions array as prop, and loop over it to render. Now fix is simple but I have to find all the occurrences of this navbar, what components are passed as leftActions and rightActions, and fix it there. Instead of this, if our navbar component is designed such that while looping over the array, it wraps each component in additional div and all relative styles are applied on it. Fix become much more simple and limited to one file.

5. Visible focus state If you tabbed through the above example, you must have noticed the blue color ring around button, similar ring you can notice around links on this page. This is the default focus indicators that browser provides. Default is not very pretty 😜. You can easily hide this ring with css. But in that case, users have no idea of where the focus is. Focus indicator help users to identify the focused element on the page. So, if you get rid of default behavior make sure that you replace it with other clear indicators. Design the focus state that is clearly visible, make the focused element stand out from the rest of the content and of course suits best with your brand design.

• WAI-ARIA - Introduces ARIA suite of web standards
• Conformance Level - All WCAG 2.0 success criteria are listed here to determine if content satisfies them.

When you start developing new website or redesigning, start evaluating accessibility as early as possible. This helps to identify the fundamental problems like contrast ratio, text-size, etc early, when it is much easier to address. There are various tools available in browser itself. Comprehensive evaluation will of course possible only with real users, but the tools listed on w3 website will help a lot to resolve most of them. Last point mentioned above is the indication that accessibility does not make your site ugly, but it opens the door to innovation and include new set of constrains to the designs. Which further gives you a new ideas that lead to the product for all.