At first glance, reaching all your employees sounds simple. However, "all employees" includes not only all desk and non-desk workers but also your employees with physical disabilities.

This article describes how we at Haiilo generally deal with the matter of accessibility, how we ensure progress in this regard, and why we can only ensure partial compliance with the official Web Content Accessibility Guidelines (WCAG) in regard to your platform.

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 a task that cannot be done in one step; it needs to be split up into smaller ones. Our approach 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 checklist

To ensure that all new and updated components are aligned with the WCAG standards, our quality assurance team and our software engineering team are using a checklist based on the official W3 WCAG guidelines. All new or updated code items 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 an area-hidden="true" set.
• Screen readers find meaningful content on buttons and links: Form buttons and links have a descriptive value, and 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: The 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: It is visually perceptible which element has the keyboard focused once the user starts navigating 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. 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

To make sure that already optimized components stay accessible and to document the overall progress of reaching the goal of WCAG 2.1 AA compliance, we have these two measures.

• Frequent WCAG tests from a third party: At least every half a year, we order a BITV/WCAG test to be conducted by the BSVH. The results give us an indication of the progress and reveal gaps in Haiilo's accessibility. Customers are also conducting their own internal tests and sending us their results.
• Violations are treated as bugs: Every revealed violation of the WCAG guideline of an already optimized component is treated as a bug and will, therefore, be fixed within the SLA resolution times. The resolution times vary based on the severity and service level of the customer.

Partial compliance

As mentioned, we are generally interested and working towards broad compliance with the WCAG standard. However, one thing to keep in mind is that Haiilo is highly adjustable and contains vast amounts of user-generated data. Because of the created content, complete compliance can't be assured - so it will be partially compliant. Nevertheless, we aim 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 a company's needs. One thing that can be configured and modified is color and theming. By default, we 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 - text, images, videos, or a combination. In this case, it is up to the user/editor to provide accessibility standards. We will assist the user with this matter where possible and technically feasible. 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 providing an alternative text option 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 acts 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 continuously improves the application's accessibility and takes this topic very seriously. With every new release, there will be improvements in this matter. We have a process in place that ensures our components are tested against WCAG guidelines. Our components are maintained and regularly checked upon the guidelines internally and by third parties.

Despite the above-mentioned catalog of measures, we are happy to receive your feedback if you stumble across a non-WCAG-compliant part of a component. Please contact our Service Desk for assistance.