HDS Accessibility
The Helsinki Design System is designed and built to be accessible for all, regardless of ability or situation.
Accessibility in the City of Helsinki digital services
The basis of HDS accessibility is
an EU directive on web accessibilitywhich mandates that all new public sector websites published by 23.09.2019 have to comply with WCAG 2.0 Standard at AA Level. On 23.09.2020 all websites, new and old, have to meet this criterion. HDS aims to make the life of projects easier by providing components, patterns, and guidelines that meet these requirements.
Standards behind HDS development
Following the EU directive, HDS aims to fulfill WCAG 2.0 Standard at AA Level.
However, HDS follows the newer WCAG 2.1 Standard. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0 and W3C advice to use it. Even though the EU directive requires fulfilling the standard at the AA level, HDS also implements many requirements from the AAA level.
In addition to WCAG 2.1 and 2.0, HDS also refers to the following guidelines:
- WCAG 2.2 Standard (draft) at AA level. This is done for future-proofing reasons even though the requirements are not part of the official WCAG requirements yet.
- The City of Helsinki content accessibility guidelines . They are heavily based on WCAG requirements but still include good extra practices.
- Develop with Helsinki - accessibility guidelines for developers .
HDS accessibility process
New components and patterns are not released before their accessibility has been audited by a third-party auditor. This includes components marked as Drafts. If components or patterns are released without an audit, they will be indicated in the documentation. This may happen if the component is quickly needed by some project or if it takes a considerably long time to make the component accessible.
Component accessibility is ensured in all stages of HDS design and development. The process is following:
- During the design phase, auditors will comment on the designs from a visual perspective. They will also give pointers on which parts of the design may cause challenges for accessibility during implementation.
- During the implementation specification phase, auditors will comment on the specifications from the accessibility point of view. Specifications will include things like keyboard navigation, usage of aria features, etc.
- During implementation, auditors will actively test the component and suggest changes if needed.
- During the documentation phase, auditors will read through the documentation and suggest changes and clarifications if needed.
- After all phases have been accepted by the auditors, the component will be marked with the following status label in the HDS documentation: Accessible
Accessibility in projects using HDS
HDS promises to ensure component and pattern level accessibility. This means that a project that uses HDS components and patterns and follows HDS guidelines can trust that these parts of the service are accessible. However, if the components are used in other ways or use cases than specified in the HDS documentation, HDS cannot promise accessibility. It is good to keep in mind that using HDS does not alone make the service accessible!
Here are some things projects should take into account when designing accessible services using HDS:
- Get at least a basic level familiarity of WCAG 2.0 Standard at AA Level. Your service is required to follow WCAG guidelines at A and AA levels.
- HDS components allow a lot of customisation. When customising component colours, ensure accessibility. For more information, refer to HDS Colours - Customising colours documentation.
- When designing components that are not part of the HDS, you are required to ensure accessibility by yourself. It may help to refer to HDS components for good accessibility design and implementation practices. You may also contact the HDS team if you need assistance.