Reach all employees. Sounds simple at first glance. However, "all employees" includes not just all desk and non-desk workers, but also your employees with physical disabilities.
This article describes how we at Haiilo generally deal with the issue of accessibility at Haiilo, how Haiilo ensures progress in this regard and why Haiilo can only ensure a partial compliance to the official WCAG guidelines in regards to your digital home.
Accessibility in general
According to the Web Content Accessibility Guidelines (WCAG), accessibility encompasses "a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. [...] These guidelines also make web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general".
Making an application WCAG 2.1 AA compliant is therefore a task that cannot be done in one step, needs to be split up into smaller ones. The approach we have chosen is to divide this task into individual components without losing sight of the big picture - starting with the features that are the focus for those users.
Quality assurance
To make sure that all new and updated components are aligned with the WCAG standards, our quality assurance team as well as software engineering are using a checklist based on the official W3 WCAG guidelines.
All new or updated code items which are visible to the user will be checked against this list and rejected if they do not comply.
The mentioned list contains the following items:
Textual alternatives
- All images and icons that are relevant for the understanding have an appropriate, equivalent text alternative.
Voice over
- Decorative images are hidden for screen readers: Images that are decorative only or redundant (e.g. avatar images next to a user name) have area-hidden="true" set.
- Screen readers find meaningful content on buttons/links: Form buttons and links have a descriptive value and/or screen readers find meaningful content to read aloud.
- Form controls have labels assigned: Labels are associated with form elements. If no label is available, the form fields have an ARIA label so that screen readers can read out the purpose of the form control.
Keyboard Navigation
- Intuitive keyboard navigation: Reading and navigation order is logical and intuitive. Users can understand and follow the focus when navigating via the keyboard/screen reader.
- Accessible via the keyboard: Every component and functionality is available using the keyboard and a screen reader (except for explicitly hidden components). Interactive elements are accessible via the TAB key even without a keyboard.
- Active HTML elements are recognizable as such: It is visually perceptible which element has the keyboard focused once the user starts navigation with the keyboard/screen reader.
Contrasts
- A minimum contrast of 3:1 should be maintained between foreground and background for large text and icons and 4.5:1 for small and normal text..
- Deactivated elements should maintain the minimum contrast if they convey information. Both the contrast to the background and the contrast to non-deactivated elements of the same appearance should be sufficient (3.0:1).
Form fields and error messages
- Form controls have labels assigned: Labels are associated with form elements. If no label is available, the form fields have an ARIA label so that screen readers can read out the purpose of the form control.
- The user is guided through error handling: The user is intuitively guided through form errors after submitting the form. Error messages are readily accessible and the user can easily fix errors and resubmit the form.
WCAG tests and regression
In order to make sure that already optimized components stay accessible and to document the overall progress of reaching the goal of being WCAG 2.1 AA compliant, we installed 2 measures.
- Frequent WCAG tests from a third party: At least every half a year we are ordering a BITV/WCAG test which is being conducted by the BSVH. The results are giving us an indication of the progress and revealing gaps in Haiilo's accessibility. Additionally, customers are conducting their own internal tests and are sending us their results.
- Violations are treated as bugs: Every revealed violation to the WCAG guideline of an already optimized component is treated as a bug and will therefore be fixed within the applying SLA resolutions times. The resolution times are varying based on the severity and service level of the customer.
Partial compliance
As mentioned, we are generally interested and working towards a broad compliance with the WCAG standard. Though, one thing to keep in mind is that Haiilo is highly adjustable and contains huge amounts of user-generated data. Especially because of the created content, a complete compliance can’t be assured - so it will be partially compliant. Nevertheless, our goal is to get as close as possible so that users with disabilities can use Haiilo.
Color criteria
Haiilo is highly adjustable and can be adapted to the company's needs. One thing that can be configured and modified is color and theming. By default, we are going to provide a theme for Haiilo out of the box that meets all criteria for color and contrast - especially providing consistent hover and active states for controls.
However, once a company alters the design to appear in the corporate identity, it is the responsibility of that company to adjust colors and color schemes according to the WCAG guidelines.
Content criteria
Haiilo allows editors and users to generate content - which can be text, images, videos, or a combination of those. In this case, it is up to the user/editor to provide accessibility standards. Where possible and technically feasible we will try to assist the user in doing so. For example, we do not allow editors to use H1 elements within the rich text editor since there is supposed to be only one H1 element per page which is reserved for the page's headline.
For images, we are working on providing an alternative text wherever possible. This is already working for most of the images provided by editors but is still missing in some widgets.
Regarding video content, Haiilo is acting solely as the platform to distribute and show the video content. Providing accessible videos (e.g. by displaying subtitles or a sign language interpreter) is the task of the underlying video platform or needs to be added to the video content beforehand.
Conclusion
Haiilo is continuously improving the accessibility of the application and takes this topic very seriously. With every new release, there are and will be improvements in this matter. We have a process in place that ensures that new and updated components are tested against WCAG guidelines. Additionally, already updated components are maintained and regularly checked upon the guidelines internally and by third parties.
Despite the above-mentioned catalogue of measures, have you stumbled across non-WCAG-compliant parts of already updated components? We are happy to receive your feedback. Feel free to let us know via bug ticket.