This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.

User Experience (UX) Designer Responsibilities in Accessibility Roles and Responsibilities Mapping (ARRM)

This is an in-progress draft. We welcome your comments via GitHub or email from the links below under Help improve this page. You are also welcome to join the ARRM Community Group to contribute.

Role summary

UX Designers can potentially cover numerous related areas, from conceptualizing the user journey to partial front-end development. For the purposes of this resource, UX Design is defined by its core responsibilities, such as information architecture, creating wireframes (low fidelity screen mockups), and creating prototypes that define interactions.

Key deliverable examples:
User journeys, wireframes, prototypes, interaction guidelines, information architecture
Tasks include:
User workflow / process maps, designing user experiences, user task and workflow mapping, creating and maintaining user personas
Example job titles for this role:
User Experience (UX) Designer, Product Designer, Web Designer, Service Designer

Tasks to get started

Below is a list of tasks for UX designers to get started making your work more accessible to disabled people. If these design tasks aren’t met, your designs can create barriers to users with disabilities.

You can also get the full list of Tasks Involved in Accessibility as a web page with other roles, or download the CSV file.

ID WCAG Level Task

Case study: How to use the tasks

A good way to get familiar with the tasks is to do a short case study. Think about how you might tackle the task in your role. Then, think of how meeting this task impacts an end user.

Task

NAV-024: Setting the focus to a new element doesn’t automatically trigger a context change, such as content updates or the opening of new windows.

Primary Role: UX Designer

“As the primary owner of this task, I will add annotations to my design document(s). They will identify which elements on the page receive keyboard focus.

I will include this instruction for Front-end developers: implement the interactive elements in a way that, when the element receives focus, it doesn’t automatically trigger a context change on the page.”

Secondary Role: Visual Designer

The secondary owner of the task is the Visual Designer. They may have designed content to appear on the screen once a button receives focus and is selected.

Explain the behaviour and functionality that you intend as the UX Designer and primary owner. For example, if the button receives focus, it shouldn’t automatically show the content. It should be user-controlled; the user needs to select the button for it to display.

Collaborating on the design together ensures that it’s optimized for multiple end users.

End user persona: Lakshmi, a senior accountant member who is blind

Lakshmi is blind and uses a screen reader (speech-to-text software) and keyboard to navigate web pages. She uses websites daily for research and financial transactions. This design task ensures she isn’t confused by an unexpected behaviour, i.e., when her keyboard focus lands on a button for the first time and content is announced automatically or the button automatically opens another page.

The intent of the task is to ensure that functionality is predictable as visitors navigate their way through a document.

This task helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.

Read Lakshmi’s full story and learn about other design tasks that benefit users like her.

Additional resources

Draft review questions

Back to Top

This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.