Accessibility
Overview
In every one of Avalara's apps, accessibility for all users is vital. We are striving for compliance with WCAG 2.1 Level AA standards. In Skylab SDK, we have implemented ARIA role and label attributes where it was appropriate and possible for components that would be used in a variety of contexts. We have also implemented event handlers that allow for keyboard navigation in components that require it. Individual Skylab SDK elements may need further ARIA attributes and adjustments depending on the context in which they are used, in order to be accessible to those using screen readers or keyboard-only navigation, and this is left to the app developers. Guidance for accessibility is provided in the Guidelines section on each Skylab SDK element's detail page.
Keyboard Navigation in Firefox on MacOS
Firefox on MacOS follows the Keyboard navigation in the System Settings`. If this feature
is disabled, then Firefox will not set the focus to certain elements, such as anchors. In order to make Firefox
respond to keyboard inputs in an accessible manner, go to the Apple Menu, System Settings,
Keyboad on the left pane, Keyboard navigation in the right pane. Enable the toggle switch.
Click on the Keyboard shortcuts, select Keyboard from the left pane and verify all options in
the right pane are checked/enabled.
Use native HTML elements as intended
When implementing components that Skylab SDK does not provide, use native HTML elements for their intended purpose
whenever
possible, rather than mimicking an existing element’s functionality with a different one. For example, an element that
links to an external page should be an <a>, rather than a <button> that uses a
click handler to load a new page. If custom implementation is
necessary, be careful when assigning ARIA roles. The use of an ARIA role implies that the element conforms exactly to
the role’s guidelines in every way, including keyboard navigation and association of labels with content. Be sure to
visit ARIA Design Pattern Examples
for thorough guidance regarding different elements and their required keyboard commands, ARIA roles, and ARIA
attributes.
Testing
As a first step, perform a simple accessibility audit of your app's pages using two Google Chrome plugins: WAVE and axe. Resolve any issues those plugins identify. There are occasional false positives in those tools and they only catch subset of accessibility issues which can be checked automatically, but this will help. Once you have remedied the plugins' findings, add axe tests to your CI/CD process using the instructions in the Automated Accessibility Testing wiki.
Then perform manual testing of your app using keyboard-only navigation in order to find keyboard traps (a region that
can be entered, but not exited, using keyboard navigation) and interactive elements that are not in the tab order.
Navigating your app using a screen reader (such as VoiceOver for Mac or NVDA for Windows) can be challenging, but is extremely helpful in catching issues that an
automated audit like Lighthouse can't detect. Many WCAG compliance issues can be solved by properly adding a role or labeling elements,
such as standalone icons, using aria-label or aria-labelledby, and using a screen reader can
help you determine which elements need these labels.
Resources
An excellent introduction to accessibility best practices
WCAG 2.1 success criteria and techniques
MDN accessibility documentation
A11ycasts -- accessibility tutorial videos
Lighthouse -- accessibility audit tool