Front-End Developer 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
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 Deliverables
- HTML and CSS files
- Client-side scripting
- JavaScript libraries and frameworks
- Etc.
Tasks include
- Pattern libraries and prototypes
- Template functionalities
- Semantically-rich HTML document structures and widgets
- Use and adapt frameworks and content management systems
- Etc.
Example job titles for this role
Front End Developer, Web Developer, Full-Stack Developer, UI/UX Developer, JavaScript Developer, UI/UX 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.
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 | Level | Task |
|---|---|---|---|
| IMG-020 | 1.4.5 | AA | Text that is placed on top of an image is handled semantically through HTML and CSS instead. |
| SEM-002 | 1.3.1 | A | HTML elements are used according to the HTML specification. |
| SEM-008 | 1.3.1 | A | HTML elements are used based on the semantics they provide, not based on what they look like. |
| SEM-011 | 1.3.1 | A | Elements that act as headings are marked up as such. |
| SEM-017 | 1.3.2 | A | The source code (or DOM) order matches the suggested visual order of the design. |
| INP-004 | 2.1.1 | A | All actionable elements can be reached, using only the keyboard. |
| INP-005 | 2.1.1 | A | All active elements can be triggered, using only the keyboard. |
| INP-012 | 2.1.2 | A | Users can navigate away from all active elements, using only the keyboard. |
| INP-015 | 2.4.3 | A | Users can tab through active elements in an order that reflects the intended interaction order of the design. |
| INP-018 | 2.4.7 | AA | Every element that receives keyboard focus displays a visible focus indicator. |
| FRM-001 | 1.3.1 | A | Text labels are marked up using the label element or other equivalent means. |
| FRM-007 | 1.3.1 | A | Instructions and messages are programmatically conveyed to assistive technologies. |
| FRM-009 | 1.3.1 | A | Required fields are programmatically conveyed as such to assistive technologies. |
| CSS-014 | 1.4.4 | AA | CSS techniques are used to ensure that content doesn't overflow, overlap or get truncated as a result of increasing the text size. |
| NAV-012 | 2.4.1 | A | Skip links and similar mechanisms point to the expected destination. |
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.