Posted on by Leon Hampson in Testing
A user story usually focuses on the value a software feature will deliver to an end-user, and an accessibility user story is no different. Whether you need to write an accessibility user story to fix issues found in an accessibility review, as part of a business case, or as part of your service delivery plan, there’s not much that you need to do differently.
Your end-user might have a persona that differs from some of your other user personas, have different needs, or interact differently from how other users interact with your product. Technical or QA requirements may be slightly different or more detailed than you might be used to providing, but the basic outline is the same:
As you move on from the high-level acceptance criteria to refining the detail, you can then start identifying any requirement for specialist coding knowledge, for example, WAI-ARIA, or testing criteria needed to meet your Definition of Done. To do this you will need to understand how people with disabilities browsing with assistive technologies navigate and experience the web.
Remember, understand the feature from the perspective of the end-user and the benefits they will receive, just as you would with any user story.
Allocating time and resources to accessibility planning in your development lifecycle also benefits your business. As well as resulting in a more inclusive product, it can help avoid expensive mistakes which need to be remedied when accessibility is only considered after a feature has been released. This is especially true if accessibility standards haven't been met which might result in a legal case being brought forward.
Below are some examples of accessibility user stories you might find helpful. Each user story is a response to a particular issue but focuses on the user, their needs, and the benefit they gain from the feature.
As a keyboard-only user, I want to know where I am on the screen so that I can perform an action or navigate to other areas of the site.
In this example, an accessibility review found that active links and buttons had no visible indication of keyboard focus. As a result, people browsing with a keyboard can find it difficult to navigate or use buttons when they don’t know which element has focus.
The following video shows how you can test visible focus as well as keyboard order.
Transcript
[A dark purple background appears with the TetraLogical logo in the top left corner]
Quick accessibility test: Keyboard support
[An image appears of a person in a lab coat typing on a black keyboard]
Many people are unable to use a mouse or touch gestures due to limited arm movement and dexterity issues. Instead they may rely on a keyboard, or similar input device, to navigate and operate digital content.
[The TetraLogical "Services" page fades into view]
To find out if your website is keyboard accessible, load the site, and start navigating it by pressing the Tab key on your keyboard.
[A purple "Skip to main content" button appears at the top of the screen. As the user navigates, the visible focus indicator moves through the links]
You should be able to reach all actionable controls, such as links, buttons, and form fields.
Pressing the Enter key or Spacebar should activate these controls.
[A link on the page from the TetraLogical website is activated with the Enter key and a new page is loaded]
If any actionable element on your website is skipped, receives the focus in an illogical order, or you cannot see where the focus is at any time, then keyboard support is not properly implemented.
[The screen fades to the same dark purple as the beginning of the video]
To find out more about accessibility, visit our website at tetralogical.com.
As a screen reader user, I want to hear the text equivalent for each image button so that I will know what function it performs.
In this example, an accessibility review found that the icons on a mobile navigation menu had no accessible name or text description, making images inaccessible for people browsing with a mobile screen reader. As a result, screen reader users are unable to navigate using the menu as they didn’t know the purpose of the links.
As a user who is colour blind, I want links to be distinguishable on the page so that I can find the links and navigate the site.
In this example, the accessibility review found there were no underlines or borders for links so they are only identified by a colour change from the surrounding text. Colour-blind users and users with low vision can't access colour and meaning and can find it difficult to distinguish colour differences, especially if there isn’t a strong colour contrast between the text and the link. As a result, they will find it difficult to perceive the links.
In conclusion, accessibility user stories are just like any other user story and focus on the value and benefits a feature will provide to people who might use your product in different ways. Understanding how people will use your product or site using accessible personas makes it easier to understand how to bring those benefits to them, and to the business.
Find out more about accessibility assessments at TetraLogical and how people with disabilities browse the web using assistive technologies.
Updated Thursday 2 March 2023.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。