Front-End Developer Responsibilities in Accessibility Roles and Responsibilities Mapping (ARRM)
Role summary
Front-End Development typically builds the parts of a product that will be interacted with by the user - specifically, the user interface. For the purpose of this resource, front end development refers to the implementation or codification of the design in functional templates for a product using technologies such as HTML, CSS and JavaScript.
- Key deliverable examples:
- HTML and CSS files, client-side scripting, JavaScript libraries, and frameworks
- Tasks include:
- Pattern libraries and prototypes, template functionalities, semantically-rich HTML document structures and widgets, use and adapt frameworks, and content management systems
- Example job titles for this role:
- Front End Developer, Web Developer, Full-Stack Developer, UI/UX Developer, JavaScript Developer, UI/UX Engineer, and Software Engineer
Tasks to get started
Below is a list of tasks for Front-End Developers to get started making your work more accessible to disabled people. If these tasks aren’t met, your code can create barriers to users with disabilities.
Important notes:
- This resource does not set requirements to meet WCAG.
- This is not a definitive list of accessibility tasks.
- Some tasks support accessibility beyond what WCAG requires.
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 SC | Task |
|---|---|---|
| IMG-003 | 1.1.1 Non-text Content (A) | Purely decorative images are provided with null alt attribute values (or other equivalent means). |
| IMG-004 | 1.1.1 Non-text Content (A) | Null alt attribute values are used for images that are already described in text in adjacent page content. |
| IMG-005 | 1.1.1 Non-text Content (A) | Adjacent linked images and text links pointing the same URL are combined into single links. |
| IMG-007 | 1.1.1 Non-text Content (A) | Informative images are marked up as foreground images, and not embedded as part of the CSS. |
| IMG-009 | 1.1.1 Non-text Content (A) | The purpose or function of complex images is conveyed using a text description, via an alt attribute. |
| IMG-012 | 1.1.1 Non-text Content (A) | The full explanation of complex images is provided through the longdesc attribute (or other equivalent means). |
| IMG-015 | 1.1.1 Non-text Content (A) | Text alternatives of dynamically updated images are simultaneously updated as the images change. |
| IMG-020 | 1.4.5 Images of Text (AA) | Text that is placed on top of an image is handled semantically through HTML and CSS instead. |
| SEM-001 | 1.3.1 Info and Relationships (A) | Informative content is provided through HTML markup. |
| SEM-002 | 1.3.1 Info and Relationships (A) | HTML elements are used according to the HTML specification. |
| SEM-003 | 1.3.1 Info and Relationships (A) | Navigation groupings are marked up using HTML list or nav elements (or other equivalent means). |
| SEM-004 | 1.3.1 Info and Relationships (A) | Header sections are marked up using HTML header elements (or other equivalent means). |
| SEM-005 | 1.3.1 Info and Relationships (A) | The main section of a page is marked up using a HTML main element (or other equivalent means). |
| SEM-006 | 1.3.1 Info and Relationships (A) | The footer of the page is marked up using a HTML footer element (or other equivalent means). |
| SEM-007 | 1.3.1 Info and Relationships (A) | Content that is complementary to the main section is marked up using HTML aside elements (or other equivalent means). |
| SEM-008 | 1.3.1 Info and Relationships (A) | HTML elements are used based on the semantics they provide, not based on what they look like. |
| SEM-009 | 1.3.1 Info and Relationships (A) | Decorative elements are embedded through the CSS presentation layer (or other equivalent means). |
| SEM-010 | 1.3.1 Info and Relationships (A) | All scripting behaviors are handled through JavaScript. |
| SEM-011 | 1.3.1 Info and Relationships (A) | Elements that act as headings are marked up as such. |
| SEM-013 | 1.3.1 Info and Relationships (A) | Headings are marked up using h1 to h6 elements or other equivalent means. |
| SEM-014 | 1.3.1 Info and Relationships (A) | Page contains a level 1 heading that describes the page content. |
| SEM-015 | 1.3.1 Info and Relationships (A) | Whitespace or pre-formatted text is not used to render content to appear as multiple columns or tabular information. |
| SEM-016 | 1.3.1 Info and Relationships (A) | Use of native, semantic HTML elements are prioritized over other methods. |
| SEM-017 | 1.3.2 Meaningful Sequence (A) | The source code (or DOM) order matches the suggested visual order of the design. |
| SEM-021 | 2.4.3 Focus Order (A) | The tab order logically and predictably follows the expected interaction order of the visual design. |
| SEM-024 | 4.1.1 Parsing (Obsolete and removed) (A) | Source code is properly nested, according to its specification. |
| SEM-025 | 4.1.1 Parsing (Obsolete and removed) (A) | Source code elements are provided with complete start and end tags (or are self-closed) according to specification. |
| SEM-026 | 4.1.1 Parsing (Obsolete and removed) (A) | ID attribute values assigned to elements are unique. |
| SEM-027 | 4.1.1 Parsing (Obsolete and removed) (A) | Elements do not contain duplicate attributes. |
| SEM-029 | 4.1.2 Name, Role, Value (A) | iFrames are implemented using title attribute values that describe their content or purpose. |
| INP-004 | 2.1.1 Keyboard (A) | All actionable elements can be reached, using only the keyboard. |
| INP-005 | 2.1.1 Keyboard (A) | All active elements can be triggered, using only the keyboard. |
| INP-006 | 2.1.1 Keyboard (A) | Device-specific programmatic event handlers are not used as the only way to trigger interactions. |
| INP-009 | 2.1.1 Keyboard (A) | Keyboard focus is not applied to non-active or static elements. |
| INP-010 | 2.1.1 Keyboard (A) | Custom active elements replicate all inherent keyboard behaviors of native active HTML elements. |
| INP-011 | 2.1.1 Keyboard (A) | Non-interactive elements are not assigned JavaScript event handlers. |
| INP-012 | 2.1.2 No Keyboard Trap (A) | Users can navigate away from all active elements, using only the keyboard. |
| INP-015 | 2.4.3 Focus Order (A) | Users can tab through active elements in an order that reflects the intended interaction order of the design. |
| INP-016 | 2.4.3 Focus Order (A) | Tabindex attributes are not assigned positive integer values. |
| INP-018 | 2.4.7 Focus Visible (AA) | Every element that receives keyboard focus displays a visible focus indicator. |
| INP-025 | 2.5.8 Target Size (Minimum) (AA) | Any programmatic grouping of controls has a target area of at least 24 by 24 CSS pixels. |
| FRM-001 | 1.3.1 Info and Relationships (A) | Text labels are marked up using the label element or other equivalent means. |
| FRM-002 | 1.3.1 Info and Relationships (A) | Text labels and form controls are programmatically associated (using the FOR and ID attributes, or equivalent means). |
| FRM-003 | 1.3.1 Info and Relationships (A) | Submit buttons in forms rely on a submit input type, a button element, or other equivalent means. |
| FRM-004 | 1.3.1 Info and Relationships (A) | Related form controls are programmatically associated using fieldset and legend elements or other equivalent means. |
| FRM-005 | 1.3.1 Info and Relationships (A) | Long option lists in select elements are grouped semantically (using the optgroup element, or other equivalent means). |
| FRM-007 | 1.3.1 Info and Relationships (A) | Instructions and messages are programmatically conveyed to assistive technologies. |
| FRM-008 | 1.3.1 Info and Relationships (A) | Use of native HTML controls are prioritized over other methods. |
| FRM-009 | 1.3.1 Info and Relationships (A) | Required fields are programmatically conveyed as such to assistive technologies. |
| FRM-010 | 1.3.1 Info and Relationships (A) | Instructions on how to use forms are programmatically conveyed to assistive technologies. |
| FRM-013 | 1.3.5 Identify Input Purpose (AA) | Data entry fields using the autocomplete attribute for previously entered information are set to the appropriate value. |
| FRM-014 | 1.3.6 Identify Purpose (AAA) | The purpose of user interface components, icons, and regions is implemented using markup languages, in a way that can be programmatically determined. |
| FRM-015 | 2.4.3 Focus Order (A) | Keyboard focus is dynamically moved to the error message when errors are returned. |
| FRM-019 | 3.2.2 On Input (A) | Event handlers are not used to automatically trigger a change of context upon input that would otherwise require explicit user action unless previously communicated. |
| FRM-028 | 3.3.2 Labels or Instructions (A) | Form controls are coded to have persistent visual labels. |
| FRM-034 | 3.3.2 Labels or Instructions (AA) | Instructions intending to prevent errors are provided in text and available. |
| CSS-002 | 1.1.1 Non-text Content (A) | The meaning of icon fonts is determined programmatically using the aria-label attribute (or other equivalent means). |
| CSS-003 | 1.1.1 Non-text Content (A) | Icon fonts whose default accessible name do not represent what the icon is, are overwritten using an aria-hidden attribute (or other equivalent means). |
| CSS-004 | 1.1.1 Non-text Content (A) | Background images identified as decorative are implemented as such. |
| CSS-005 | 1.3.1 Info and Relationships (A) | CSS pseudo-selectors such as :before and :after are not used to integrate informative content. |
| CSS-007 | 1.3.3 Sensory Characteristics (A) | Users relying on High Contrast themes don't lose information as a result of doing so. |
| CSS-014 | 1.4.4 Resize Text (AA) | CSS techniques are used to ensure that content doesn't overflow, overlap or get truncated as a result of increasing the text size. |
| CSS-015 | 1.4.5 Images of Text (AA) | CSS background sprites don't include images of text, unless equivalent text alternatives are also provided as part of the HTML. |
| CSS-022 | 2.4.7 Focus Visible (AA) | The CSS outline property of objects that receive keyboard focus are not set to zero or none. |
| NAV-012 | 2.4.1 Bypass Blocks (A) | Skip links and similar mechanisms point to the expected destination. |
| NAV-013 | 2.4.3 Focus Order (A) | All active elements receive focus in a logical and predictable order that is prescribed by the visual presentation. |
| NAV-015 | 2.4.3 Focus Order (A) | Objects that are not actionable are not part of the tabbing order. |
| NAV-016 | 2.4.3 Focus Order (A) | Focus is sent back to the initiating point when modal dialogs and controls are dismissed. |
| NAV-017 | 2.4.3 Focus Order (A) | Event handlers do not unexpectedly send the focus somewhere else on the page. |
| NAV-019 | 2.4.4 Link Purpose (In Context) (A) | Links are marked up using the anchor element and have a valid href attribute value (or use other equivalent means). |
| NAV-031 | 3.2.5 Change on Request (AAA) | Links that open new windows indicate they will do so, either as part of the link text, or using aria-label or equivalent means. |
| TAB-001 | 1.3.1 Info and Relationships (A) | Tables are only to be used to lay out tabular information or data. |
| TAB-004 | 1.3.1 Info and Relationships (A) | Tabular data and corresponding header cells for that data are part of the same table. |
| TAB-005 | 1.3.1 Info and Relationships (A) | Header cells for rows are marked up using THEAD elements. |
| TAB-006 | 1.3.1 Info and Relationships (A) | Header cells for columns are marked up using TH elements. |
| TAB-007 | 1.3.1 Info and Relationships (A) | The relationship between table header rows and table header columns with data cells in simple data tables is provided through the SCOPE attributes. |
| TAB-008 | 1.3.1 Info and Relationships (A) | The relationship between table header rows and table header columns with data cells in complex data tables is provided through the HEADERS and ID attributes. |
| TAB-009 | 1.3.1 Info and Relationships (A) | Caption elements are used to associate caption information with data tables. |
| TAB-012 | 1.3.1 Info and Relationships (A) | Tables are not used for layout purposes. |
| TAB-013 | 1.3.1 Info and Relationships (A) | Tables are not used to layout lists. |
| TAB-014 | 1.3.1 Info and Relationships (A) | Caption elements, aria-labelledby attributes or other equivalent means are used to explain the structure of data tables. |
| TAB-016 | 1.3.2 Meaningful Sequence (A) | The programmatic order of the table content matches the intended reading order, so not to affect its meaning. |
| ANM-023 | 1.4.2 Audio Control (A) | Volume controls for page-level multimedia files are independent from general computer audio controls. |
| ANM-025 | 1.4.2 Audio Control (A) | Audio content that automatically starts on page load lasts no longer than 3 seconds. |
| ANM-029 | 2.1.1 Keyboard (A) | Multimedia player controls can be fully operated using only the keyboard. |
| ANM-036 | 2.3.3 Animation from Interactions (AAA) | Animation features that create the illusion of movement support prefers-reduced-motion (or other equivalent means). |
| ANM-037 | 4.1.2 Name, Role, Value (A) | Information conveyed by multimedia player controls are programmatically announced through assistive technologies. |
| SCT-003 | 1.3.1 Info and Relationships (A) | Proper markup is used to render emphasized, bolded text and other stylistic or presentational effects. |
| SCT-004 | 1.3.1 Info and Relationships (A) | Proper markup is used to structure quotes, blockquotes and citations. |
| SCT-005 | 1.3.1 Info and Relationships (A) | Heading markup is only used for text which acts as a section heading. |
| SCT-006 | 1.3.1 Info and Relationships (A) | Heading markup is not used for formatting effects. |
| SCT-008 | 1.3.2 Meaningful Sequence (A) | The intended reading order of the content remains logical when CSS and images are turned off. |
| SCT-009 | 1.3.2 Meaningful Sequence (A) | The source code order reflects the intended reading order of the document. |
| SCT-015 | 1.4.5 Images of Text (AA) | Mathematical formulas are marked up using MathML. |
| SCT-018 | 3.1.1 Language of Page (A) | The primary language used in the document is properly identified using the lang attribute. |
| SCT-023 | 3.1.4 Abbreviations (AAA) | Abbreviations are programmatically associated with their definition. |
| DYN-004 | 4.1.3 Status Messages (AA) | Status, toast, or similar messages are programmatically determined through WAI-ARIA roles or properties, so they can be presented to assistive technology users without receiving focus. |
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:
INP-004: All actionable elements can be reached, using only the keyboard.
Primary Role: Front-End Developer
As a Front-End Developer, I will code all functionality of the content, on a web page and/or within individual components and elements, to ensure it is operable through a keyboard interface only. This also allows switch control systems to operate.
Secondary Role: UX Designer
As the UX Designer in support of the Front-End Developer, I will ensure to annotate my designs, wireframes and prototypes to clearly define the functionality of components on the page and the expected reading order to allow a keyboard user access to the page content.
End User persona 1: Marta, a marketing assistant who is deaf and blind
Marta is a marketing assistant who is deaf and recently became legally blind too, which means she can see only small portions of a screen and read text when it is significantly enlarged. She uses screen magnification software to enlarge the text on websites to a suitable font size, displays text on a refreshable Braille device and a large computer screen with high resolution and high luminosity (brightness).
The viewport, or area that Kaseem sees when the screen is magnified, is very small. So the focus must be in or very close to that ‘viewport’ at all times. Shifting it unexpectedly to a completely different areas of the screen makes it very difficult to find and then move to that area, especially if she has no idea where the focus has landed. The focus could move to another area on the page, or to a completely new page.
End user persona 2: Lakshmi, senior accountant who is blind
Lakshmi is blind. She is a semopr accountant at an insurance company that uses web-based documents and forms over a corporate intranet and like many other blind computer users, she does not read Braille.
Lakshmi relies on the screen reader assistive technology to let her know where she is on the web page. Moving the focus unexpectedly breaks the context of the page and her mental map or perception of the page.
Additional resources
- Use the WAI Tips for Developing to get started.
- See the WAI Tutorials for menus, tables, forms and more.
- Review the WAI-ARIA Authoring Practices Guide (APG) for keyboard functionality for ARIA components.