Accessibility
Featured method
Challenge the design team by evaluating the interactions of a scenario you made in a storyboard or similar. How would the interactions look like if your target user was color blind, dyslectic or had a temporary disability such as a broken arm?
Prototype & Test
Where do I start?
The best way to develop websites/applications that is useful and accessible to all is to have it in mind from the start of your process. If you have implemented an inclusive mindset from the start, all people will benefit. A good way to approach disability is to think in the direction of how Microsoft’s inclusive design Toolkit (2016. p. 21-22) states:
“Disability is not equal to a personal health condition. Disability is equal to mismatched human interactions.”
With that in mind, try to develop websites/applications that challenge the normative patterns of how we interact with them.
Introducing POUR
W3C or World Wide Web Consortium has made guidelines to make the Web more accessible to all. Their current guide is called WCAG 2.1 and is considered to be the international standard for accessibility. To make your interface inclusive, the recommendation is that it should at least measure up to at least Level AA (, there’s also level A and level AAA). This is for example is the minimum requirement for public sectors websites in EU member states as of September 2018 (Siteimprove 2019). The foundation of these criteria is based upon 4 principles: perceivable, operable, understandable and robust.
Perceivable
Operable
Understandable
Robust
WCAG 2.1 - Level AA - Simplified
The information on this site derives from the W3C World Wide Web Consortium Recommendation as well as the WCAG checklist from the Swedish Agency for Digital Government in association with the Swedish Post and Telecom Authority. This list aims to give a short introduction to the guidelines, however, it should not be used in any way as a definite guide to determine whether your project is accessible. For that purpose, it is recommended to read the W3C World Wide Web Consortium Recommendation for the official guidelines.
Web Content Accessibility Guidelines 2.1, W3C World Wide Web Consortium Recommendation 21 May 2019. https://www.w3.org/TR/WCAG21/(2019-05-21)
Myndigheten för digital förvaltning (DIGG) in co-operation with Post- och telestyrelsen (2019). WCAG – standard för tillgänglighet. https://webbriktlinjer.se/wcag/?checklista (2019-05-23)
Perceivable
Give your users opportunity to have an alternative to non-text content.
1.1.1 Non-text Content
There are situations were this criteria do not apply, which you can read more about in their guide (see link).
Offer your users text-based option to any non-text content on your site.
1.2.1 Audio-only and Video-only (Prerecorded)
Offer and inform your users an option if a recording only include audio or video.
1.2.2 Captions (Prerecorded)
Include captions for all video, audio and animations. Inform users of the option.
1.2.3 Audio Description or Media Alternative (Prerecorded)
Offer synchronized audio description for your media recordings and inform users of the option.
1.2.4 Captions (Live)
Provide captions for live audio content/synchronized media and inform users of the option.
1.2.5 Audio Description (Prerecorded)
Include audio descriptions for prerecorded video content and inform users of the option.
Create an adaptable user interface, like a simplified layout, without loosing any information and keeping structure intact.
1.3.1 Info and Relationships
Provide information in your code about your contents attributes and role.
1.3.2 Meaningful Sequence
Present your content on your user interface in a ordered and understandable way to all.
1.3.3 Sensory Characteristics
Do not make instructions for understanding and operating your user interface that solely rely on for example color, size and sound to convey meaning.
1.3.4 Orientation
Make sure your content is presented properly regardless of the orientation of the screen unless it is essential.
1.3.5 Identify Input Purpose
Help your users by identifying any input field that collects data giving them the option of auto-fill except when there might be sensitive information. Declaring what data is expected to be filled also makes filling in the form a simpler task.
Simplify your user interface, separating foreground from background in order for your users to see and hear content.
1.4.1 Use of Color
Do not solely rely on color to convey meaning or indicate action in your content.
1.4.2 Audio Control
If there is audio that plays automatically for more than 3 seconds, there should be an option either to stop, pause or control volume independent from the overall system volume level.
1.4.3 Contrast (Minimum)
The contrast in your text and images of text in your user interface should at least have the ratio of 4.5.1. For the exceptions, read the official guideline.
1.4.4 Resize text
Without any assistive technology, text should be able to be resized up to 200 percent without loosing content or functionality. However, this does not apply to images of text or captions.
1.4.5 Images of Text
With the exception of logos/essential and visually customizable images of text, try to rather use text to convey meaning or information.
1.4.10 Reflow
Create a flexible layout that works on a small screen as well as an enlarged screen.
1.4.11 Non-text Contrast
For user interface components and graphics, have at least a 3:1 contrast ratio against adjacent colors in order to make them distinguishable to all.
1.4.12 Text Spacing
Make sure that users have the option to enlarge spacing in line height, paragraphs, letters, and words without losing content or functionality.
1.4.13 Content on Hover or Focus
On pointer hover and keyboard focus, make sure it is easy to handle by all. This includes assistive technologies. It should be easy to dismiss, hoverable and persistent in a way that it remains visible until dismissed.
Operable
All functionality on the user interface should be available from a keyboard.
2.1.1 Keyboard
Develop your user interface so that it is operable through only a keyboard.
2.1.2 No Keyboard Trap
Make sure the marker does not get stuck when using only a keyboard.
2.1.4 Character Key Shortcuts
Be careful when creating character key shortcut by only using well-known combinations and make sure to inform your user if so.
Give your users enough time to read and use your content.
2.2.1 Timing Adjustable
Provide your users with the option to adjust any time limits in your content.
2.2.2 Pause, Stop, Hide
Provide users with the opportunity to pause, stop and hide any moving, blinking or scrolling information/auto-updating content that lasts over for 5 seconds. It also applies if the content starts automatically and is presented parallel with other content.
Do not design content that may cause seizures.
2.3.1 Three Flashes or Below Threshold
Do not cause epileptic seizures through flashing lights. There should be a maximum of three flashes going from light to dark or vice versa, in a one second period.
Provide users with options to navigate, find content and determine where they are on your interface.
2.4.1 Bypass Blocks
Provide users an opportunity to skip repeating content.
2.4.2 Page Titled
Title your page in a describing manner of topic, without making the description too long.
2.4.3 Focus Order
Make sure the focus(tab) order on the user interface is proper and logically organized.
2.4.4 Link Purpose (In Context)
Make sure the purpose of a link can be conveyed from the link text alone.
2.4.5 Multiple Ways
Offer multiple ways to navigate on the user interface.
2.4.6 Headings and Labels
Write descriptive headings and labels with a clear purpose.
2.4.7 Focus Visible
When using keyboard navigation, there should be a clear focus indicator.
Provide users with the opportunity to use the functionality on the interface with inputs beyond the keyboard.
2.5.1 Pointer Gestures
Provide users with options to complex pointer gestures.
2.5.2 Pointer Cancellation
Provide the users with options to abort or undo a pointer action.
2.5.3 Label in Name
Make sure the text on buttons and other components is coherent with the labels in the markup language.
2.5.4 Motion Actuation
Functions that are triggered through, for example, shaking or tilting should also be able to be operable in more conventional ways.
Understandable
Make sure the content of the user interface is readable and understandable.
3.1.1 Language of Page
Automatically provide the main language of the page in your code.
3.1.2 Language of Parts
If any content is written in a language other than the page’s main language, provide information in the code.
Present the user interface in a functional and predictable way.
3.2.1 On Focus
Do not make any unexpected changes once a component of the interface is focused.
3.2.2 On Input
Do not make any unexpected changes when there is a user input action unless that behavior is expected or if the user has been informed about the change.
3.2.3 Consistent Navigation
Unless the user initializes a change, the navigation should stay consistent throughout the user interface.
3.2.4 Consistent Identification
Components providing repeating functionality should be identified consistently throughout the user interface.
Help your users avoid and correct their mistakes.
3.3.1 Error Identification
Clearly show where a mistake is located and describe what has happened.
3.3.2 Labels or Instructions
Create clear labels and instructions for times when user input is needed.
3.3.3 Error Suggestion
Unless it is a security risk, provide users with suggestions if there is a input error if it is known.
3.3.4 Error Prevention (Legal, Financial, Data)
When dealing with transactions of any kind, make sure your user has the opportunity to correct, reverse their submission, check their data and confirm.
Robust
Make sure your user interface is compatible with all browsers and accessible tools, now and in the future.
4.1.1 Parsing
Make sure your content is properly nested, ID’s are unique and that there are no duplicate attributes on elements.
4.1.2 Name, Role, Value
For all components in a user interface, the name, role and value should be programmatically determined.
4.1.3 Status Messages
Status messages can be determined through role or properties in such that they can be presented by an assistive technology without receiving focus. This is done using markup languages through programming.