-
Notifications
You must be signed in to change notification settings - Fork 11
Accessibility
Accessibility requirements are based on European directive EN 301 549 , which uses WCAG 2.1 (Web Content Accessibility Guidelines) as basis for web accessibility.
Accessibility is varied based on your device and screen reader. In this section we will try to open some of the issues we've found during our testing.
| Android version | Browser | Information |
|---|---|---|
| v7 | chrome | Android 7 with TalkBack seems to not handle element selection well. If focus indicator is in a spot where the elment is not clickable click events are called on wrong elements. Skip to main content link dosn't work on v7 TalkBack. |
| v7 | chrome | Android 7 with TalkBack has issues with texts with multiple links in them like in address view. Trying to select one link seems to inteact with another link in the same area. |
| v10 | chrome | Android 10 seems to work mostly as intended. |
| Version | Browser | Information |
|---|---|---|
| Chrome | Chrome has been tested intensively with NVDA. Accessibility mostly works as inteded with NVDA and chrome. | |
| Firefox | Firefox has been tested intensively with NVDA. There are some issues reading checkboxes and radio inputs in 2 parts. | |
| Internet Explorer | Internet explorer is not supported. | |
| Microsoft Edge | Edge does work somewhat but NVDA doesn't seem to support Edge properly. Mainly issue is NVDA arrows keys not working as inteded in Edge. |
There are certain features that do require sight to be used. We've come to decision that these features need to be hidden from screen readers in order to avoid unusable features for people that rely on screen reader. This causes issue with some users who might use both screen reader and sight to operate the site. In these cases these people will not be able to access these features with keyboard since these are hidden from screen readers. This happens because when element is hidden from screen readers the software decides to remove all functionality from element.
There might be some users who use screen reader and sight in unison. This can cause issues in certain cases. For example some interactive elements like buttons which have been hidden from screen readers because the feature it opens doesn't work for people without sight. In these cases we've had to make a decision on which users to prioritize.
We've decided to use the WCAG's perspective to follow the information given by assistive technology rather than information reliant on individual user. This means keeping these elements hidden from screen readers because these features are not meant to be used without sight. (Example features: Measuring tool, Map related functionality)
https://vm.fi/saavutettavuusdirektiivi
https://webaim.org/techniques/keyboard/
https://www.w3.org/TR/WCAG20-TECHS/
https://www.powermapper.com/tests/screen-readers/aria/
Must make sure elements, texts and interactive properties like hover and focus have proper contrast. You can read more here.
Tool for checking contrast https://webaim.org/resources/contrastchecker/
- Screen reader focus has been on NVDA and VoiceOver
- Use Headings (h1,h2) to structure your site in meaningful way. Screen readers have a way to move from heading to heading or next heading2 etc. So headings should be used in a way that allows screen reader users to move in a meaningful way.
- Since Servicemap is a SPA (Single Page Application) it was decided that h1 is always title of the application.
- DO NOT use h1,h2... for styling purposes. Headings are meant to be used for structural purposes as landmarks etc.
- Use button elements or roles when the click doesn't take user to a new page or position in page.
- If button opens content, like a collapsible element, it should not change focus and should have a aria-pressed attribute which is toggled on click. This way screen reader tells user that button is pressed or not pressed. Giving control to user to proceed on their own pace.
- Avoid using disorienting autofocus if possible.
- If using another element as a button use role="button" attribute
- Use role="dialog" on modal elements.
- Make sure user can't leave modal element with tab or arrow keys.
- Have close button that closes the modal and returns user to previous position
- Links are elements that take the user to either new page or completely different part of the current page.
- If element is not a link element it should have a role="link" to pass the information to screen readers
- Link should describe what it does. (example "from here" -> "Buy tickets from here")
- Avoid multiple subsequent links to same page
- If element contains only icon it should have a aria-label to describe the action
- Image should contain descriptive alt text or be hidden from screen readers
- Texts over images must follow color contrast standard
- Links with heading text which is read first for fast browsing capabilities
- Small description text for further information if required
- For long lists use pagination for easier browsing. Long lists don't work well for screen reader users since they have to browse through everything when moving back and forth. Pagination helps this by reducing "visible" result size and allowing user to easily jump through content by just choosing page.
- Using transparent outline on focus elements shows focus indicator on windows high contrast mode without changing visually anything in normal view
- Good trick for custom modal dialogs is having and element that loops focus back to start automatically in onFocus event