Labcodes believes in web environments made for all people. Confetti follows the global accessibility standard (WCAG) AA Level and try our best to comply with AAA requirements.

Principles

From W3C's Web Accessibility Initiative

All users must have access to, be able to use, and understand the same content, no matter what disability they might have or what sort of device they might be using to get at that content.

All content should be/have:

• Perceivable information and user interface
• Operable user interface and navigation
• Understandable information and user interface
• Robust content and reliable interpretation

Resources

• Labcodes' Web Accessibility Guide
• World Wide Web Consortium (W3C)‘s Web Accessibility Initiative (WAI)
• Web Content Accessibility Guidelines
• Video on disabled and aria-disabled elements

aria-disabled vs disabled

All of our inputs and buttons have disabled and ariaDisabled props. We made both available because setting them as disabled makes them unreadable by screen readers, and it could lead some visually impaired users to not know what are the available options.

Whenever any of our components are set with ariaDisabled, they are functionally identical to their disabled counterparts, with the exception that they will be read by screen readers, so we strongly suggest using them whenever possible.

For specific cases, like elements that can be skipped to finish a task and don’t add information to the context, you may opt to use disabled, so that they can be skipped in tab order.

Also, when using these props on forms, consider using aria-live and aria-describedby to improve the experience on screen readers. References can be found on W3C's website and MDN docs

Automatic tests

Text Editor

By having ESLint enabled with the Airbnb Accessibility Configs, whenever we write a piece of code that doesn’t follow the accessibility guidelines, we receive a visual warning. Depending on the project, we should choose whether or not to go further and prevent code merging altogether if the accessibility requirements are not met, by using tools like husky, for example.

Browser

• Perform Lighthouse Audit Testing from browser's dev tools or extension (Chrome) or locally use A11y Command-line Tools to audit your page
• Use Spectrum extension to test colors for different visual impairments
• No Coffee (Chrome Plugin): to simulate all levels of vision loss.
• Line Height Adjuster (Chrome Plugin): To test compliance with Text Spacing guideline
• Dyslexia Unscrambled (Chrome Plugin): transforms any webpage into one that is more easily readable by those who are dyslexic.

Manual tests

Set an environment that reproduces the restrictions of a disability, like removing the mouse or using a screen reader.

• Check if everything is reachable from keyboard: tab through links and all form and video controls to see if they receive focus.
• Use assistive technology like a screen reader or switch controls to test all features
• NVDA (Windows - Open Source)
• VoiceOver (Apple)
• JAWS (Windows - Paid)
• Do not hide actions on behaviors that are not available for mobile devices, like hover states. It should be avoided even when an alternative method is provided for such screen types.
• Check if all images have an alt text set.
• Always ensure that the HTML uses semantic tags on components.