Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.
UX Designer Responsibilities Mapping
Parent document: https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping
Contents
User Experience 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, or 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 Designer Roles & End User Needs: Case Study
Checkpoint:
NAV-023: Multiple mechanisms are provided for wayfinding (ex. breadcrumbs, search features, site map, progress bar, steps, etc).
UX Designer
Decisions on wayfinding through a website and individual web pages can come from multiple stakeholders and roles. For this checkpoint, the UX Designer is the Primary owner.
Here are some ways other roles could be involved to support completion of this checkpoint - i.e., there are multiple mechanisms for wayfinding on the site:
- Business may provide a starting point with requirements based upon industry or company standards (Contributor).
- UX Designers, working from the initial business requirements will incorporate them with the overall goals of the site along with user research to identify what is the best set of methods to put into the site (Primary).
- The UX Designer documents these decisions in the functional specifications and low fidelity wireframes. From there the Visual Designer will create the presentation as with any other feature. (Secondary)
- Depending on the complexity of some features, such as site search, the UX Designer may need to consult with the Front-end Developer for specific options available (Secondary or Contributor).
- Content Authors will provide standard names for elements as needed. (Secondary)
- The Front-end Developer will incorporate all of the above into the final implementation. (Secondary or Contributor)
End user: Preety
Preety is a middle school student with attention deficit hyperactivity disorder with dyslexia. Although she has substantial difficulty reading, she particularly enjoys her literature class.
She experiences problems with online content when the navigation is not clearly evident. She finds websites and apps that provide multiple means of navigation such as a navigation bar, search box, bread-crumb trails, and a sitemap to be much easier to use.
Users with cognitive needs can benefit from multiple ways of wayfinding on a website or individual page.
Other designs that help:
- Clearly structured content that facilitates overview and orientation
- Consistent labeling of forms, buttons, and other content parts
- Predictable link targets, functionality, and overall interaction
- Different ways of navigating websites, such as hierarchical menu and search
- Options to suppress blinking, flickering, flashing, and otherwise distracting content
- Simpler text that is supplemented by images, graphs, and other illustrations
UX Design Checkpoints – Starter List
| ID | WCAG SC | Conformance Level | Content Type | Checkpoint | Main Role | Role Ownership | ||
|---|---|---|---|---|---|---|---|---|
| Primary | Secondary | Contributor(s) | ||||||
| AMN-022 | 1.4.2 | A | Audio Controls | Multimedia player controls are provided to turn sound on and off. | Design | UX Design | none | none |
| AMN-026 | [1] | A | Audio controls | Prerecorded or live video content is not set to auto-play. | Design | UX Design | none | none |
| FRM-025 | [2] | A | Form Interactions | Form controls are designed to have persistent visual labels. | Design | UX Design | Visual Design | none |
| FRM-030 | [3] | AA | Form Interactions | Text-based instructions are provided to help users correct errors. | Design | UX Design | Content Authoring, Visual Design | none |
| FRM-031 | [4] | AA | Form Interactions | Users are provided with means to prevent and correct form errors. | Design | UX Design | Business | none |
| NAV-014 | [5] | A | Navigation | A logical and predictable focus order is defined for complex interactions. | Design | UX Design | none | none |
| INP-024 | [6] | A | Input Modalities | Keyboard focus does not move automatically from one form control to the next. | Design | UX Design | Front-end Development | none |
| KBD-004 | 2.1.1 | A | Keyboard Access | Programmatically scripted behaviors are planned for both hover and focus states. | Design | UX Design | Visual Design | none |
| KBD-005 | 2.1.1 | A | Keyboard Access | Keyboard focus states are planned for every active elements. | Design | UX Design | Visual Design | none |
| FRM-030 | 3.3.3 | AA | Form interactions | Cues are provided to help users correct errors. | Design | UX Design | Visual Design | none |
| CSS-013 | 1.4.4 | AA | CSS Presentation | Users can resize the text on the page up to 200% without any loss of content or functionality. | Design | UX Design | Front End Development | Visual Design |
| NAV-005 | 2.2.1 | A | Navigation | Options to extend, or even turn off time limits are provided. | Design | UX Design | Business | none |
| NAV-006 | 2.2.2 | A | Navigation | Users given means to pause, stop or hide content that automatically updates. | Design | UX Design | none | none |
| NAV-011 | 2.4.1 | A | Navigation | The expected destination of skip links and similar mechanisms are defined. | Design | UX Design | none | none |
| NAV-015 | 2.4.3 | A | Navigation | A logical and predictable focus order is defined for complex interactions. | Design | UX Design | Visual Design | none |
| NAV-017 | 2.4.3 | A | Navigation | Focus is sent back to the initiating point when modal dialogs and controls are dismissed. | Design | UX Design | Front End Development | none |
| NAV-028 | 3.2.3 | AA | Navigation | Navigation structures are consistent across the site or application. | Design | UX Design | none | none |
UX Design Checkpoints
| ID | WCAG SC | Conformance Level | Content Type | Checkpoint | Main Role | Role Ownership | ||
|---|---|---|---|---|---|---|---|---|
| Primary | Secondary | Contributor(s) | ||||||
| IMG-011 | 1.1.1 | A | Images and Graphs | A mechanism that conveys the way through which the full explanation of complex images is defined. | Design | UX Design | none | none |
| DOC-021 | 4.1.2 | A | Document Structure | Tracking or hidden Iframes are defined as such through the title attribute value. | Design | UX Design | none | Content Authoring |
| KBD-004 | 2.1.1 | A | Keyboard Access | Programmatically scripted behaviors are planned for both hover and focus states. | Design | UX Design | Visual Design | none |
| KBD-005 | 2.1.1 | A | Keyboard Access | Keyboard focus states are planned for every active elements. | Design | UX Design | Visual Design | none |
| KBD-012 | 3.2.2 | A | Keyboard Access | Keyboard focus does not move automatically from one form control to the next. | Design | UX Design | Front End Development | none |
| FRM-015 | 3.2.2 | A | Form interactions | Forms are designed to not automatically submitted without the user's explicit intent. | Design | UX Design | none | none |
| FRM-029 | 3.3.2 | A | Form interactions | Placeholder text is not used in lieu of regular text label elements. | Design | UX Design | none | none |
| FRM-030 | 3.3.3 | AA | Form interactions | Cues are provided to help users correct errors. | Design | UX Design | Visual Design | none |
| FRM-031 | 3.3.4 | AA | Form interactions | Users are provided with means to prevent and correct form errors. | Design | UX Design | none | none |
| FRM-032 | 3.3.4 | AA | Form interactions | Confirmation screens are provided prior to any final form submission. | Design | UX Design | none | Business |
| CSS-001 | 1.1.1 | A | CSS Presentation | Icon fonts used to convey information are provided with a text equivalent. | Design | UX Design | Content Authoring | none |
| CSS-013 | 1.4.4 | AA | CSS Presentation | Users can resize the text on the page up to 200% without any loss of content or functionality. | Design | UX Design | Front End Development | Visual Design |
| NAV-004 | 2.2.1 | A | Navigation | Users are notified when time limits are about to expire. | Design | UX Design | Business | none |
| NAV-005 | 2.2.1 | A | Navigation | Options to extend, or even turn off time limits are provided. | Design | UX Design | Business | none |
| NAV-006 | 2.2.2 | A | Navigation | Users given means to pause, stop or hide content that automatically updates. | 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-011 | 2.4.1 | A | Navigation | The expected destination of skip links and similar mechanisms are defined. | Design | UX Design | none | none |
| NAV-015 | 2.4.3 | A | Navigation | A logical and predictable focus order is defined for complex interactions. | Design | UX Design | Visual Design | none |
| NAV-017 | 2.4.3 | A | Navigation | Focus is sent back to the initiating point when modal dialogs and controls are dismissed. | Design | UX Design | Front End Development | none |
| NAV-023 | 2.4.5 | AA | Navigation | Multiple mechanisms are provided for way finding (ex. breadcrumbs, search features, site map, progress bar, steps, etc). | Design | UX Design | none | none |
| NAV-027 | 3.2.3 | AA | Navigation | Consistent navigation patterns are provided site-wide. | Design | UX Design | none | none |
| NAV-028 | 3.2.3 | AA | Navigation | Navigation structures are consistent across the site or application. | Design | UX Design | none | none |
| NAV-029 | 3.2.3 | AA | Navigation | Navigational graphics and icons always lead to the same destination. | Design | UX Design | Visual Design | Content Author |
| NAV-030 | 3.2.3 | AA | Navigation | Navigational graphics and icons always to serve the same purpose. | Design | UX Design | Visual Design | Content Author |
UX Design Decision Tree Examples
Example 1
Checkpoints
- I want different ways to navigate the site such as site search, consistent menus, breadcrumb links and possibly a site map.
- I want instructions to on how to correctly enter information.
- I want error messages presented by each field with incorrect values.
- I want a confirmation screen to review before any final form submission.
- I want a warning message before time limits are about expire and the ability to continue.
- I want the ability to stop any automatically updating content like carousels.
Business Analysts may be concerned about forms or other features but rarely at this level.
Q2: Is this visual design? No
These checkpoints have presentation aspects but they are centered around core functions or feature definition that come before defining their presentation .
Q3: Is this content authoring? No
Text content is definitely involved with all of these checkpoints but, as with visual design, authoring would come after deciding how they will be implemented.
Q4: Is this UX Design? Yes
These checkpoints define primary features and operation that are the responsibility of the UX Designer. Decisions on features typically come early in product definition in functional specifications, requirements or user stories before any final presentation, content or implementation begin.
The UX Designer will almost certainly work with the Visual Designer to work out the presentation of these features and have the Content Author provide the text used. Depending on the technical requirements Front-End Developers may be consulted to confirm the feasibility which may influence the UX Designers options.
Example 2
Checkpoints
- I want the keyboard focus to advance across the page in a meaningful way.
- I want links to allow skipping past repetitive sections of page elements (like header navigation) when using the keyboard.
- I want logical, predictable keyboard operation when interacting with any user interface component, especially any that are not standard HTML.
Business Analysts are not concerned with such issues.
Q2: Is this visual design? No
These examples mainly center on keyboard operation, not presentation, which is not the Visual Designer's primary concern.
Q3: Is this content authoring? No
Similarly to the Visual Designer, these checkpoints are about keyboard operation, not content. The Content Author would only be asked to provide text after the decision has been made and only if any is needed at all.
Q4: Is this UX Design? Yes
Checkpoints about keyboard operation and user interaction are the domain of the UX Designer. They rely on understanding the needs of the users which a key responsibility of that role to interpret and define.
To the extent there is a visual aspect to operational checkpoints, the UX Designer may consult with the Visual Designer. The same is true when considering any text presented to users and the need to consult the Content Author. The UX Designer should provide Front-End Developers with specifications about keystrokes and operation but may not need to consult with them to make these decisions.
