-
Notifications
You must be signed in to change notification settings - Fork 28
High level use cases
This document is the output of a series of workshops held on the ARIA-AT weekly calls.
We did this exercise as a preparation for designing a user interface to support the project.
We’ve tried to identify situations of struggles and desired outcomes of our target users.
Taking this user-centred approach will help us design and develop the user interface more efficiently.
This document is a work in progress. Tell us your thoughts or feedback via this issue.
- Use cases of website developers
- Use cases of Assistive Technologies (AT) developers
- Use cases of testing instructions contributors
- Use cases of testers
- Use cases of ARIA-AT project administrators
I’m developing a web-based user interface. I want to make it accessible. But I'm not sure which ARIA attributes are well supported across different browsers and screen readers.
- As many users as possible find the interface I'm developing easy to use.
- I'm done with this user story as quickly as possible.
- If someone reports an issue, I know whether the problem is with my code or with a browser / screen reader.
- I feel more and more competent (rather than discouraged).
I’m developing a web-based user interface. The code I’ve written isn’t producing the results I expected. Am I doing something wrong? Is there a bug in my codebase? Or is it an issue with the browser or screen reader? Or maybe there's nothing wrong. I’m actually not sure how this screen reader is expected to behave.
- I know whether there's a problem with my code.
- As many users as possible find the interface I'm developing easy to use.
- I'm done with this user story as quickly as possible.
- I feel more and more competent (rather than discouraged).
I want the screen reader I’m working on to offer good support for an ARIA attribute. But it's not clear what supporting this attribute means. It's difficult to know how the attribute should be rendered in different situations. There are diverging opinions about what good looks like.
- Our product makes it easier for our customers to use the web, and they are satisfied.
- I'm done designing / implementing this feature as quickly as possible.
Customers say they're having issues with our screen reader when using a well-known website. It’s hard to know what the problem is, and whether the responsibility falls on us. It’s likely that the website’s developers have used some ARIA attribute incorrectly. But there’s also debate about how that attribute should be used, and rendered to users.
- When customers report issues, it's clear whether these issues are caused by our screen reader or by websites.
- Website developers use ARIA in ways that offer a good user experience, so that our customers are satisfied.
My team and I are working to improve a screen reader’s support for ARIA. We need to prioritise our efforts. But we don’t have a clear view of exactly where our current implementation is incomplete, broken, or fails to meet customers’ expectations.
- We are confident that we're focusing our efforts on what matters the most to our customers.
- Our customers are satisfied.
I’m concerned that the screen reader I’m working on is not going to be evaluated in the right way, and that results made public might not be fair. I don’t know/believe that the tests assertions are based on a correct understanding of how my screen reader should work.
- The screen reader I work on has a good reputation, and doesn’t get unfair criticism.
Support for ARIA on the Web is not as good and consistent as I'd like it to be. I want to help make things better. I'm thinking of contributing test instructions for the ARIA-AT project.
- The web is more accessible.
- I feel that I'm helping make the web as accessible as I'd like it to be.
I am responsible for a screen reader. I care for its reputation. I want to make sure that it’s being tested and evaluated in the right way – following the right instructions and with correct expectations.
- The screen reader I work on has a good reputation, and doesn’t get unfair criticism.
- I feel that I'm helping make the web as accessible as I'd like it to be.
I do some testing to learn more about how screen readers support and render ARIA attributes. But testing and collating test results on my own feels futile. There's just too much to do. I want to help move things forward.
- I feel more competent and confident in my knowledge of ARIA and screen readers.
- Ensuring that websites are accessible feels easier to me.
I do some testing to learn more about how screen readers support and render ARIA attributes. I think that I might have found a browser / screen reader bug. But I’m not sure whether I’m interpreting things correctly.
- Know whether what they're seeing is a bug or not.
- I feel more competent and confident in my knowledge of ARIA and screen readers.
- Ensuring that websites are accessible feels easier to me.
I have found a browser / screen reader bug related to ARIA. I want everyone to be aware of this issue, so that we can get it fixed or work around it.
- I feel that I'm helping make the web more accessible, as I want it to be.
Most web pages don't use ARIA well. I want to help improve the state of things. It's hard for web developers to know how what ARIA attributes they should use and how. And what screen reader output they should expect, making testing difficult.
- It’s easy for web developers to know what ARIA attributes are well supported across browsers and screen readers.
- Screen reader users get a better, more reliable experience.
Screen readers’ support for ARIA are incomplete and inconsistent. I want to help improve the state of things. But we can't specify exactly how a screen reader should implement ARIA.
- It's easy for screen reader developers to see how well their product is supporting different ARIA attributes, and where the gaps are.
- It's easy for screen reader developers to see how their product is rendering different ARIA attribures, compared to other screen readers.
- Screen reader users get a better, more reliable experience.
I’m working on the ARIA-AT project and I'm hoping it'll be a success. I'm concerned that screen reader developers might not agree with the test results that the project publishes – because we might not be able to get enough time with them to define test assertions together. I'm concerned that the project might lose credibility and momentum if there are disagreements about the expected outputs of different screen readers, and what counts as ’supports’, ‘doesn’t support’ or ‘incorrect support’.
- Possible disagreements about what screen reader outputs constitute ‘support’ are resolved efficiently.
- The ARIA-AT probject progresses with good momentum.
- Screen reader developers see the assessments we produce as credible.