Accessibility
The If Design System provides accessible markup which will serve as a foundation for your application development. In order to make sure you build accessible components, however, you will need to follow the accessibility guidance for our interactive components. This includes keyboard behavior as well as the management of ARIA roles and properties.
</
“A website is not necessarily universally designed, even though it is in line with the current requirements and guidelines.”
Table of Contents
Edit this section, Opens in new windowOverview
What is Accessibility?
Web accessibility ensures that people with disabilities can perceive, understand, navigate, interact with, and contribute to the applications you create. This means that pages are Perceivable, Operable, Understandable and Robust. This includes providing keyboard interaction alternatives for all mouse-based actions, properly identifying all form fields and buttons, providing text based alternatives for all images, videos, icons and SVGs, as well as building components that properly convey their identity, operation model, and state to assistive technologies.
The design system enables accessible development by providing a set of semantically correct components, each with appropriate ARIA markup so they can be identified correctly to users of assistive technologies.
"Accessibility issues are not technical debt, they are critical bugs" - Alexander V. R-H
Get that into your heads! #AccessibilityMatters #uu #wcag
Standards Compliant Markup
The semantic markup and use of ARIA roles in our components are based on W3C standards and industry best practices. This markup is the perfect starting point for building accessible components.
Keyboard Navigation
While we do not provide the JavaScript that is necessary to make our components interactive, we offer advice on how to use scripting languages to create keyboard-accessible components.
Appropriate use of color
Our components aspire to follow the two main rules of accessibility as it relates to color:
- We never use color as the only means of providing information or requesting an action.
- The combinations of text and their background colors do not fall below the WCAG recommended threshold ratio of 7:1 for standard or small text and 7:1 for larger text.
Accessible Forms
Our forms offer proper use of <fieldset class="if">
and <legend>
tags as well as appropriate labeling for input controls. Our radio button and checkbox controls provide a balanced solution that offers accessibility as well as design flexibility.
Images and icons
We provide a means of offering text-based alternatives for all images, icons and SVGs.
Component Identity
Our interactive components are created in accordance with the latest ARIA Authoring Practices, with attributes that are understandable by screen reader users on key page elements. It is important to note that as a component is interacted with, the ARIA attributes may need updating to reflect the new state. Hence, we provided detailed guidance on how and when to do this.
Validating your applications
The design system is only the foundation for accessible application development. We recommend that you review the accessibility of your applications before release and ensure that it meets the WCAG Standard at the AA Level.
Resources for accessibility
- W3C Web Accessibility Initiative
- WAI-ARIA Authoring Practices
- 7 Things Every Designer Needs to Know about Accessibility
- Accessible Interface Design: on designing with accessible color contrast ratios
- WebAIM
- The A11Y Project
Testing
There is currently no documentation for this section yet. However, there might be some more documentation after this section.
Contact the Design System team, Opens in new window for questions.
If you want to contribute, you can also add the documentation yourself!, Opens in new window
Extensions





Screen readers
There are occasional instances where content should be made available to screen reader users, but hidden from sighted users. In most cases, if content (particularly content that provides functionality or interactivity) is important enough to provide to screen reader users, it should probably be made available to all users. Cases where verbose cues or instructions are provided only for screen reader users are most likely a reflection of poor design and accessibility. However, there are a few cases where information is apparent visually, but may not be apparent to screen reader users. In these cases, it may be appropriate to mark-up content in a way that it is read by a screen reader, but invisible to sighted users.
You can use the class .if.sr-only
to accomplish this.
<div class="if …">
<img class="if …" … />
<span class="if axe sr-only">Descriptive text to the image</span>
</div>
Automated
“Automatic testing of WCAG undoubtedly contributes to both quality and efficiency, but it often reveals only the tip of the iceberg. I believe human evaluation and user testing are absolutely necessary when we work on creating solutions that can be used by everyone in any situation. The effect of seeing and knowing the problems associated with disability itself should also not be underestimated”