UX Designer Responsibilities Mapping
Parent document: https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping
User Experience (UX) Design
The role of UX Design can potentially cover a large number of related areas: from exploratory user research (like user interviews, ethnographic research, etc.) 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)
- creating prototypes that define interactions
- testing designs for usability
Key Deliverables
- Wireframes
- Prototypes
- Interaction guidelines
- Information architecture
- Etc.
Tasks include
- User workflow / process maps
- Usability testing
- User interviews and analysis
- User task and workflow mapping
- Creating and maintaining user personas
- Etc.
Example job titles for this role
User Experience (UX) Designer, Service Designer, Interaction Designer, Information Architect, User Researcher, UX Researcher, User Experience Analyst, Usability Specialist
UX Design Checkpoints: Starter List
Here is a list of checkpoints for UX designers to get started. If these design checkpoints aren't met, your design can cause significant barriers to users.
This list is taken from the full list of UX Design checkpoints.
For all role checkpoints, see the Accessibility Checkpoint Full List [1].
| ID | WCAG SC | Conformance Level | Content Type | Checkpoint | Main Role | Role Ownership | ||
|---|---|---|---|---|---|---|---|---|
| Primary | Secondary | Contributor(s) | ||||||
| INP-008 | 2.1.1 | A | Input Methods | Keyboard focus states are planned for every active element. | Design | UX Design | Visual Design | none |
| INP-007 | 2.1.1 | A | Input Methods | Behaviors for hover and focus states are planned and included with the design assets. | Design | UX Design | Visual Design | none |
| NAV-014 | 2.4.3 | A | Navigation | A logical and predictable focus order is defined for complex interactions. | Design | UX Design | none | none |
| INP-024 | 3.2.2 | A | Input Methods | Keyboard focus does not move automatically from one form control to the next. | Design | UX Design | Front-End Development | none |
| NAV-024 | 3.2.1 | AA | Navigation | Setting the focus to a new element doesn't automatically trigger a context change, such as content updates or the opening of new windows. | Design | UX Design | Front-End Development | none |
| DYN-003 | 4.1.3 | AA | Dynamic Interactions | Status messages are announced by assistive technologies without affecting the focus. | Design | UX Design | Front-End Development | none |
| NAV-006 | 2.2.2 | A | Navigation | Users are given means to pause, stop or hide content that automatically updates. | Design | UX Design | Visual Design | None |
| ANM-022 | 1.4.2 | A | Audio Controls | Multimedia player controls are provided to turn sound on and off. | Design | UX Design | none | none |
| NAV-009 | 2.4.1 | A | Navigation | Users can bypass blocks of content using skip links or similar mechanisms. | Design | UX Design | none | none |
| NAV-020 | 2.4.5 | A | Navigation | Multiple mechanisms are provided for wayfinding, such as navigation menus, breadcrumbs, search features, site map, progress bar, steps, etc. | Design | UX Design | none | none |
| NAV-026 | 3.2.3 | AA | Navigation | Navigation mechanisms are repeated consistently throughout the site or application in the same relative order. | Design | UX Design | Visual Design | None |
| FRM-029 | 3.3.2 | A | Form Interactions | Form controls are designed to have persistent visual labels. | Design | UX Design | Visual Design | none |
| FRM-020 | 3.2.2 | A | Form Interactions | Form interactions are not designed to include automatic changes of context upon input that would otherwise require explicit user action unless previously communicated. | Design | UX Design | Front-End Development | none |
| FRM-036 | 3.3.4 | AA | Form Interactions | Users are provided with means to prevent and correct form errors when legal, financial, or data information is involved. | Design | UX Design | Business | none |
| FRM-035 | 3.3.3 | AA | Form Interactions | Text-based instructions are provided to help users correct errors. | Design | UX Design | Content Authoring Visual Design |
none |
Case Study: How to use the Starter List
A good way to get familiar with the checkpoints is to do a short case study. Think about how you might tackle the checkpoint in your role.
Then, think of how meeting this checkpoint impacts an end user.
Checkpoint:
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 checkpoint, 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 checkpoint 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: Ilya, a senior staff member who is blind
Ilya 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 checkpoint 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 checkpoint is to ensure that functionality is predictable as visitors navigate their way through a document.
This checkpoint helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.
Read Ilya's full story and learn about other design checkpoints that benefit users like her.
Resources
- Use the Tips for Designing to get started.
- See the WAI Tutorials for common web components and how to make them accessible.
Exercise: Role-based Decision Tree Example
Who is the primary owner of this checkpoint NAV-024?
Let's get started on 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.
Using the Role-based Decision Tree, let's see how we might assign ownership.
No. Business Analysts are not involved in decisions directly related to the functionality of a website or app.
Step B: Is this checkpoint about content authoring?
No. The element may contain some text and/or have an accessible name or label, but the content is not directly related to this checkpoint.
Step C: Is this checkpoint about UX design?
Yes. This checkpoint is related to ensuring that the way the interaction of an element is designed, it doesn't behave in a certain way. Meaning, when a user brings focus to the element, this doesn't automatically trigger a change to it. The user must take the next action.
It is primarily the designer's responsibility to dictate how elements will behave (or not behave), and to annotate this clearly in their design specifications (specs) documentation that is shared with developers (and content authors if necessary).
Step D: Is this about checkpoint visual design?
No.
Step E: Is this checkpoint about front-end development?
No.
Step F: Is this checkpoint about testing?
No.
The exercise ends at Step C, as it's been determined that the primary owner of this checkpoint is the UX Designer.
Does this checkpoint require a secondary owner?
Yes, the Front-End Developer is a secondary owner as they will implement the functionality. The UX Designer's role is to annotate the interactions in their designs to give clear instructions for development.
Does this checkpoint require a contributor?
No.
Try it for yourself!
Try the exercise with another checkpoint from the Starter List above.