The web is for everyone regardless of their abilities or the way they consume it. Bedrock is committed to designing and developing inclusive experiences and complying with accessibility standards and best practices.
By designing and developing in an inclusive manner, Bedrock not only helps users with disabilities but provide a better user experience for everyone. End users should all have access to the same (product) functionalities and experience a product of high quality.
WCAGPermalink to: WCAG
All Bedrock components comply with the WCAG AA 2.1 guidelines(external link), which guarantees that they — in isolation — provide an accessible experience within the four main principles of the WCAG guidelines:
- Perception
- Operable
- Understandable
- Robust
The following explanations are excerpts from wcag.com's page about the four principles(external link):
PerceptionPermalink to: Perception
Information must be presented in a way that users can perceive it using one of their senses. In other words, a user must be able to comprehend the information presented. It can’t be blocked from all senses.
OperablePermalink to: Operable
If all users can effectively navigate your website, it’s considered operable. If your site requires users to interact in a way that’s not possible for them, your website is not meeting this principle. Users must be able to interact with the components of the page, such as navigation features and the user interface. For example, people who can’t use a mouse should be able to effectively navigate your website using just the keyboard or voice controls.
UnderstandablePermalink to: Understandable
The principle of understandable is just as it seems — users must be able to understand the information as well as understand how to operate within the user interface.
RobustPermalink to: Robust
Your content must be robust enough that it can be interpreted by a wide variety of possible user agents, including assistive technologies. In other words, your website should have maximum compatibility with current users as well as technologies that may evolve.
Important: The fact that the components in themselves comply with accessibility guidelines, does not mean that using them will create an accessible experience. As mentioned, they are accessible in isolation, but using them together in the wrong way, can result in an inaccesible experience, so please be aware of this and remember to always test your user interface in its entirety.
ARIAPermalink to: ARIA
ARIA (short for Accessible Rich Internet Applications) is a set of attributes and roles that combine to make non-native user interface elements more accessible for people who use assistive technologies, such as screen readers.
The first rule of ARIAPermalink to: The first rule of ARIA
The first rule about ARIA usage is to not use ARIA at all, if there is a native, semantic HTML element available that can do the same job. What that means is that we as designers and developers should not reinvent the wheel and come up with alternatives to tried and tested user interface elements such as checkboxes, radio buttons and selects (to name a few).
Common pitfallsPermalink to: Common pitfalls
Every year WebAIM (short for Web Accessibility In Mind) conducts an accessibility evaluation of the home pages of the top 1.000.000 web sites, and over the years the following five types of errors have consistently been the most common:
- Low contrast text
- Missing alternative text for images
- Empty links and buttons
- Missing form input labels
- Missing document language
Some of these error types are easily found using an automated tool, while others require manual testing.
KeyboardPermalink to: Keyboard
One error type that requires manual testing, and therefore does not show up in WebAIM's results, is missing support for keyboard navigation. Basically, the rule is that whatever is possible to do with a mouse (or any other pointer device) should also be possible with a keyboard.
ARIA paradoxPermalink to: ARIA paradox
Funnily enough, the WebAIM evaluation shows that pages containing ARIA roles and attributes have more accessibility errors than those without ARIA present. It's important to notice that ARIA didn't necessarily introduce those errors, but it goes to show that pages with high complexity leads to an increase in non-accessible solutions.
TestingPermalink to: Testing
In general, everything should at least be tested with the following tools/technologies:
- NVDA screen reader for Windows in combination with Chrome, Firefox and Edge browsers.
- VoiceOver for MacOS in combination with Chrome, Firefox, Edge and Safari browsers.
- Both pointer (mouse, trackpad etc.) and keyboard navigation.
When developing for mobile experiences, testing should also be performed with:
- Talkback for Android.
- VoiceOver for iOS.
ReferencesPermalink to: References
- Web Content Accessibility Guidelines (WCAG)(external link)
- MDN: ARIA(external link)
- The WebAIM Million(external link)