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.”
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 deisgn 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.
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.
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.
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.
We provide a means of offering text-based alternatives for all images, icons and SVGs.
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.
The deisgn 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.
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>
“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”