Front-End Developer Role Specific Information
The International Association of Accessibility Professionals (IAAP) created a document that “considers all 61 success criteria for WCAG 2.0 Level A, AA, and AAA against 10 roles that span software project responsibilities” (Microsoft Word, 47 KB, 15 pages).
According to the IAAP, the Front-End Developer role should:
- Ensure prototypes incorporate accessibility requirements or include approximations for elements still being developed.
- Produce accessible functional prototypes and wireframes, website master templates (HTML and CSS), as well as scripted behaviors as they are available.
- Ensure code incorporates accessibility requirements as specified and identify any gaps.
The two most important things for a front-end developer to understand are:
- the Web Content Accessibility Guidelines (WCAG), and
- the ARIA Authoring Practices (described as “the Bible of web accessibility” by one consultant)
Other good resources:
- Web Accessibility Tutorials. These are sourced from the Web Accessibility Initiative (WAI) which is part of the W3C, so they’re semi-official. Please check the date on each tutorial — if it’s more than a few years old, there’s probably a more up-to-date way to implement things.
- A11y Style Guide and Pattern Library. User-contributed code samples for common user interface elements.
- Inclusive Components by Heydon Pickering, a leading accessibility expert and the author of the book Inclusive Design Patterns.
- Web Accessibility Training for Developers (PDF, 2.1 MB, 154 pages) by Dennis Lembree, another expert who is currently with Deque Systems. These are the slides from a comprehensive, five hour long webinar that Lembree offered (for free!) on May 9, 2018. You may also read Joshua Randall’s personal notes from the webinar, which are a slightly shorter 15 pages.
- A comprehensive ARIA introduction by Patrick Lauke (2018, May 21).
- A Developer’s Guide to Better Accessibility – gives both general and specific advice. It is biased in favor of Ember (which is a product they sell) but you can ignore that.
The remainder of this page consists of links to articles, code samples, and so forth that front-end developers can use to learn about implementing digital accessibility.
However, if accessibility is not being addressed prior to the code process, then you’re being done a disservice by other roles. Encourage your business analysts (BAs), user experience (UX) team, designers, marketers, and content authors to take responsibility for digital accessibility early in the project.
Style Guides and Pattern Libraries
A style guide is a set of standards for the writing and design of documents.
The British Broadcasting Corporation (BBC) Mobile Accessibility Guidelines are “a set of technology agnostic best practices for mobile web content, hybrid and native apps”. I am particularly fond of the summary that categorizes the BBC mobile accessibility guidelines into audio & video, editorial, focus, and so forth.
A11y Style Guide and Pattern Library has some useful patterns for common UI layouts like Cards, Grids, Forms, Media, Navigation.
The A11y Project is an accessible widget and pattern library.
Inclusive Design Components – Inclusive design is the term for design that is usable to everyone. Heydon Pickering (a leading expert) put together this website to go over various key components.
For general inclusive design advice, see Microsoft’s inclusive design website, or the direct link to the Microsoft inclusive design toolkit (PDF, 3 MB, 26 pages).
The Cupper Documentation Builder by The Paciello Group is a pattern library for building pattern libraries. How meta!
eBay’s M.I.N.D. Patterns – eBay developed its patterns for Messaging (M), Input (I), Navigation (N), and Disclosure (D) with accessibility in, er, mind. As eBay describes it: “This book will assist frontend developers in building accessible e-commerce websites and components. This book is not a visual design system or a CSS framework (à la Bootstrap) – it is instead intended to complement those systems & tools.”
Developing accessible pattern libraries, Kasper Isager – explains how they used Vue.JS to make accessible patterns so that developers don’t forget to mark up everything.
Brad Frost created atomic design as “a methodology for creating design systems.” As he puts it, “interfaces are made up of smaller components. This means we can break entire interfaces down into fundamental building blocks and work up from there. That’s the basic gist of atomic design.”
This doesn’t directly relate to accessibility but it’s still good information.
ARIA (Accessible Rich Internet Applications)
Patrick Lauke of The Paciello Group has a comprehensive presentation about ARIA (on GitHub, 161 slides) (2018, May 15) that explains what it is and how to use it, with examples and pointers to other sites.
General ARIA Advice
Take some time to learn what WAI-ARIA is and where and why we use it.
In a nutshell, WAI-ARIA is meant to add semantic meaning back into to markup where a user interface technique has ignored or overridden the native meaning.
The first and most important rule of ARIA use is don’t use ARIA when you could use a native HTML element instead!
An Overview of ARIA
HTML5 Doctor overview of ARIA, that also points to the latest HTML5 spec where some ARIA info is now baked in.
Léonie Watson wrote a blog post titled “Quick guide to the ARIA specifications” (2017, May) which goes through how various specifications fit into the overall ARIA framework.
Level Access wrote an article covering the new ARIA stuff in 1.1 (compared to 1.0).
W3C Github pages with Notes on Using ARIA in HTML. Has a handy checklist at the bottom for ‘custom control design considerations’ with links to how to address many common issues.
ARIA Design Patterns. From the W3C so this is about as ‘official’ as you’re going to get.
The W3C publishes ARIA authoring practices. The linked site gives specific implementation guidelines for various design patterns and widgets, landmark regions, keyboard interfaces, and grids and tables.
The WhatSock ARIA Role Matrices list the ARIA roles with their required attributes, optional attributes, whether they require scripting, and implementation notes.
The accessibility tree is what screen readers and other assistive technology use to understand a website or app. The WhatSock website has a lengthy training section about the accessibility tree.
Websites, articles, and general advice about various topics.
Where do assistive technology errors come from?
Assistive technology (AT) compatibility issues can arise from three different sources:
- errors in the DOM (the Document Object Model)
- the browser incorrectly interpreting user interface components
- or the AT not being able to handle the code it is presented.
Front-End Developer Handbook
The front-end developer handbook by Cody Lindley aggregates information “with the intention of being a professional resource for potential and currently practicing front-end developers to equip themselves with learning materials and development tools.” It has a short section on accessibility.
Advice from Other Corporations
Microsoft’s accessibility advice – good general advice.
.NET accessibility best practices – even if you’re not using .NET, the general advice is still valid (for example, ‘show the keyboard focus’, ‘provide alternatives to color’).
- eBay’s CSS framework and accessibility – goes into detail about how eBay uses CSS in an accessible way.
Content Management Systems
Feature Specific Advice
Organized alphabetically by feature name.
W3C’s list of accessible components – use at your own risk! I haven’t vetted these.
Verified Accessibility Samples from IBM. “These code samples help developers and testers understand how different web components operate with assistive technology (AT) on desktop and mobile devices. They contain sample components along with testing results.”
Here are some resources for deciding when and how to apply alt text to images.
- How to design great alt text, Caitlin Geier. (2018, April 5). Deque Systems.
- Mediacurrent article (2015)
- W3C alt text decision tree
- W3C decription of the element and how to use with it – including detailed examples
Autocomplete (or Autosuggest)
- Creating Accessible Autocomplete (SlideShare), by Russ Weakley. (2017, September 31). Start with slide #76 for step-by-step instructions, but the whole presentation is a good read. “Takes a deep dive into how to create an auto-complete search function that is accessible to a range of different users including keyboard-only and screen reader users. Along the way, we will explore important keystrokes and aria attributes that can be used enhance the experience for all users.”
- Accessible Autosuggest Dropdown on Github (2018, April)
- Nicolas Hoffman’s automplete (2018?)
- WebAxe article about autocomplete with links to other resources
- Github accessible autocomplete project (undated)
- Webkit example of a combobox (undated)
Here are some resources on creating accessible breadcrumbs for navigation.
- W3C guidance on Breadcrumbs (using ARIA)
- W3C advice on Providing a Breadcrumb Trail
- A11y Style Guide advice on creating accessible Breadcrumbs
“Links are not buttons. Neither are divs and spans.” So writes accessibility expert Karl Groves.
A button initiates an immediate action, such as form submission.
A link triggers navigation to a different resource.
Please refer to the article referenced above, as well as the W3C guidance on Buttons (using ARIA).
Overriding default button styles, by Chris Coyier. (2018, May 9.) CCS-Tricks. “Buttons are weird! They have a good amount of default styling (that come from the User Agent Stylesheet) that varies from browser to browser and means you have work to do to get them exactly how you want.”
Bypass Blocks and Landmarks
Plug-ins Related to Bypass Blocks and Landmarks
- SkipTo on GitHub. SkipTo is a replacement for your old classic “Skipnav” link. The SkipTo script creates a drop-down menu consisting of the links to the important places on a given web page. The menu will make it easier for keyboard and screen reader users to quickly jump to the desired location by simply choosing it from the list of options.
- Landmarks browser plug-in that allows you to navigate a web page via WAI-ARIA landmarks, using the keyboard or a pop-up menu.
“The carousel paradigm for displaying content exists for one reason only: because groups fight for that coveted front and center position on a web site homepage. A carousel is one way to guarantee that each group’s content has an opportunity to have a turn in that spot.” (email conversation with Alison Walden at SapientRazorfish)
Except this doesn’t actually work. A carousel study by Erik Runyon showed that at best, fewer than 10% of visitors interacted with a carousel. Of those who did, the vast majority (54% to 89%) only ever interacted with the first slide.
Consider that non-sighted people do not need to know that you have collected content items for display in a carousel format. For a non-sighted person, the important interaction is that they can tab through each item. As they tab, relevant information should be included in the focused area so that they have context on each piece of content.
Thus, it is not necessary to place keyboard focus on the previous and next arrows, and is actually easier for keyboard users to navigate if we do not make the arrows function with the keyboard.
Tabbing from panel to panel should move the carousel the same way it would if a user clicked on the arrow keys with their mouse.
You must provide a way to pause an auto-playing carousel. This is an explicit WCAG success criterion (2.2.2 Pause, Stop, Hide).
Articles About Carousel Accessibility
- W3C Web Accessibility Tutorial on Carousel Concepts. If you must build out a carousel, at least follow this tutorial.
- The Unbearable Accessibility of Slideshows (2015, February 23) by Gian Wild. Explains some of the problems with carousels and suggests fixes.
- Medium article by Alison Walden (from SapientRazorfish) – If you must use a carousel, make it accessible (2016)
- Nicolas Hoffman – jQuery Accessible Carousel System using ARIA (2017, September 15) (note that he consistently misspells carousel as ‘carrousel’)
- Bootstrap 3.3 Carousel Accessibility Examples (2015)
- WebAxe article About Carousels and ARIA Tabs (2013)
Dialog windows, also known as modals, are a separate window that pops up in front of the main window. The main accessibility issues for dialog windows relate to focus management (retaining focus within the modal), ability to close the window using keyboard only, and what happens when the user dismisses the modal (focus should return to where the user was, or the next logical step in a process).
- W3C example modal dialog (2017)
- Yoast SEO explains what it takes to make modals accessible (2018, May 4)
- Github project with a lightweight, flexible, accessible modal dialog (2017, November)
- Creating An Accessible Modal Dialog on bitsofcode (2016)
- Marco Zehe on how to make accessible modal dialogs (2015)
Duplicate IDs within your codebase can negatively affect accessibility. They can cause problems with assistive technologies that may not be aware of programmatically updated or changed names, roles, or states where there are duplicate IDs in the script.
Form fields with duplicate IDs can make the form labels unavailable to assistive technology, or can cause one field entry in the user interface to update two or more fields on the back end.
Duplicated IDs are more than just an accessibility concern. They are something that is not part of developer best practices.
Duplicate ID Resolution Resources
- Ensuring that ID attributes are unique, W3C
- Why Unique Attribute IDs Matter, Deque Systems (2016)
- Parsing Error Bookmarklet (2012). Allows you to parse the W3C validator output to show just the errors.
Focus indicators are the box that appears around a focus-able element when you keyboard through a page. They are extremely helpful to all users, in particular sighted, keyboard-only users. Many web designs suppress the browser’s native focus indicator, which is an accessibility no-no.
- Tips for designing useful and usable focus indicators, Caitlin Geier. (2016, June 29). Deque. This article covers which elements are focus-able and gives some tips for designing your own focus indicators, because (in the author’s opinion) the default browser focus indicators aren’t strong enough.
- Force focus tools. (2018, April 9). WebAxe. A list of browser plug-ins and other tools to force the focus indicator to be visible. There are a band-aid on the underlying problem (why wasn’t the focus indicator styled to be visible to begin with?), but the tools can be helpful for navigating certain websites.
- Well Designed Forms, Lewis Phillips and Crystal Baker. 2018, March. AT&T. (slide presentation on Google Drive)
- ARIA practices about forms.
- The A11y Style Guide on forms.
- IBM’s Verified Accessibility Samples (Va11y) relating to forms — search on that page for the word ‘form’.
I remember that when we discussed Forms accessibility, you recommended that error messages should not fire until the form is submitted; i.e., not on tab-out from the form fields. However… I don’t remember *why* this was the recommendation.
answer from Alison Walden at SapientRazorfish
They can fire immediately on tab out for a sighted user, but for a non-sighted user, I believe it is better to catch the errors at the end.
The reason why is because when the user tabs out of the field, if an error is announced, it often interferes with the new field label being read that was just tabbed into.
Also, when the user tries to submit, it is a natural time to hear errors, and at that time we can programmatically place their focus on the field that has the error, making it easier for them to fix it than if they had just tabbed out, then have to tab back into the problem field.
Managing heading levels in design systems, by Heydon Pickering. (2018, April 21.) Medium. “For screen reader users, headings describe the relationships between sections and subsections and — where used correctly — provide both an outline and a means of navigation. Headings are infrastructure.”
Hiding and Showing Content
Here’s some info on working with hidden content (TPG article). It goes through the scenarios of hiding content from the various kinds of users or devices. This was written in 2012; still, it’s a nice overview and explains some of the pitfalls. The link at the top has more current “can I use” info.
The HTML lang attribute defines what language a page is written in. It is important to set this so that screen reader software can apply the proper pronunciation.
Adrian Roselli slides (2018, April 16) on the lang attribute.
See Bypass Blocks and Landmarks
The humble hyperlink can often be misunderstood or misused. Gian Wild of Sitepoint has an article on Making Accessible Links: 15 Golden Rules for Developers (2014, February 20).
Adrian Roselli’s article on Functions to Add ARIA to Tables and Lists (2018, May 12). As with all foreign code you shouldn’t blindly implement this — look at the code first to see if it does what you want.
Scott O’Hara on ARIA Lists (2018 May 26). Including a table of what the various screen readers will announce for both ordered and unordered lists.
The loading spinner is the (often hated) animated circle that appears when a page is loading content. The following article describes how to build an accessible loading spinner using only CSS.
How to create a simple CSS loading spinner & make it accessible, by Stuart Nelson. (2018, April.) Codeburst.io.
Menus and Menu Widgets
See Dialog Window.
The W3C maintains a page explaining PDF techniques for WCAG 2.0.
Adobe provides some training resources on how to use Acrobat to create accessible PDFs.
as well as additional training on how to verify PDF accessibility.
Dennis Lembree recommends that you define these with both HTML5 and ARIA to ensure backwards compatibility with screen reader and browser combinations.
defining with HTML5
- Page Header: Should include all content in the website header including logo image, search (where applicable) and main navigation. If a promo banner or message is used that is repeated on multiple pages, this should be included within the header definition. Use this HTML5 element:
- Main Navigation: Includes the main website navigation such as mega menu (including the top-level links used to open the mega menus), responsive hamburger menu and content opened by the hamburger menu. Use this HTML5 element:
- Any Navigation used on an Individual Page: Use this HTML5 element:
(various labeling methods can be used including the aria-labelledby attribute. All navigation regions must have a label so the type of navigation is specified to assistive technology)
- Main Page Content: Includes the main page content including the page h1 heading. Use this HTML5 element: …page content
- Website Footer: Includes the footer navigation links, etc. Use this HTML5 element:
- Optional HTML5 Elements:
- The HTML5
should only be used when it is important that users who cannot see the screen know that the section of content is important. For example, on a product page you may have a page section below the product listing that has content such as “You May Also Like”. In this case, it is acceptable to use the section element.
- When using the element, it should also have a label so screen reader users understand what the section of content is about. In the example here, you’d want to set the aria-labelledby attribute on the
element and have the attribute reference the id of the “You May Also Like” text (assuming this text is a heading).
- If you are using a
element on a content section that isn’t really important to distinguish from other page content, the element should either be removed or have role=”presentation” set on it. It’s not a good thing to use these in this case.
- Caveat: The HTML5 spec indicates that
elements are a good and great thing. However, they must be used carefully and appropriately. The spec says it is allowable to use multiple occurrences of them on a given page and within each section, there must be a header, an h1 heading and a footer. Although the spec indicates this, this type of structure only confuses screen reader users, as they expect only one header, one h1 heading and one footer on each HTML page.
- When using the element, it should also have a label so screen reader users understand what the section of content is about. In the example here, you’d want to set the aria-labelledby attribute on the
- The HTML5
element should only be used when the content within the element is an actual article, such as a blog post, or a paragraph that has a link after it to allow users to “read more” about a topic.
- It is not necessary to label an
- If the
element is used in the code but does not technically contain what would be considered to be an article, it should have role=”presentation” set on it or be removed from the code, whichever approach would be easier.
- It is not necessary to label an
- The HTML5
defining with ARIA
- Page Header: Should include all content in the website header including logo image, search (where applicable) and main navigation. If a promo banner or message is used that is repeated on multiple pages, this should be included. Add a role to the appropriate
:…all header content
- Main Navigation: Includes the main website navigation such as mega menu (including the top-level links used to open the mega menus), responsive hamburger menu and content opened by the hamburger menu. Add a role to the appropriate
- Any Navigation used on an Individual Page: Add a role to the appropriate
(various labeling methods can be used including the aria-labelledbyattribute. All navigation regions must have a label so the type of navigation is specified to assistive technology)
- Main Page Content: Includes the main page content including the page h1 heading. Add a role to the appropriate
- Website Footer: Includes the footer navigation links, etc. Add a role to the appropriate
role=”presentation” versus aria-hidden=”true”
The CSS Karma blog has an article on the difference between role=”presentation” and ARIA-hidden=”true”. They are not identical!
Section elements versus Div elements
HTML5 tutorial article on the use of the
compared to the
See Bypass Blocks.
Scalable Vector Graphics, or SVGs, do not become pixelated when re-sized and thus are generally superior to other approaches. SVGs are generally used for icons.
There can be some accessibility problems with SVGs relating to keyboard navigation. (put advice here)
Accessible SVG Test Page runs through examples of Content, Links, and Buttons and tests their support in the major browsers and screen readers.
SVG, Icon Fonts, and Accessibility: A Case Study, by Dennis Lembree. (2017 December 14.) 24 Accessibility. “Let’s discuss a brief history of web icons, advantages and disadvantages of several development solutions, and how a particular web app uses them.”
Tab panels allow multiple blocks of content to share horizontal space, yet make only one panel at a time visible.
- Example of an accessible tab panel in the wild, on the SAS website.
- Another accessible tab panel, on the United Kingdom’s passport application website.
- The W3C ARIA authoring guidelines for Tab Panels.
- An article about Tables, CSS Display Properties, and ARIA by Adrian Roselli (2018, February).
- Adrian Roselli’s follow-up article on Functions to Add ARIA to Tables and Lists (2018, May 12). As with all foreign code you shouldn’t blindly implement this — look at the code first to see if it does what you want.
- IBM’s WCAG HTML techniques includes some about tables. Use your browser’s find feature for the word ‘table’.
- The A11y style guide on Tables.
- W3C’s explanation of the Scope attribute used on Table elements.
- CSS Tricks has a Complete Guide to the Table Element.
- 3PlayMedia summary of their webinar on “The Future of Video Player Accessibility.” (This is a biased source, but better than nothing.)
- Stamford Interactive (a digital marketing agency) has a PDF guide to accessible video that is a pretty helpful cheat sheet overall.
- The W3C FAQ for video accessibility. This is about making the video content accessible, not about building your own player.
- MDN has an article about building out accessibility in an HTML5 player.
- Dennis Lembree, an expert who works for Deque Systems (one of the top accessibility consulting firms), gave a webinar where he covered the basics of web accessibility for developers. Slides #85 ff. have some specific advice.
- Lembree links out to the following resources… I haven’t personally vetted these but they look promising.
- PayPal accessible video player project on Github https://github.com/paypal/accessible-html5-video-player
- Ind.ie video player https://2017.ind.ie/blog/accessible-video-player/ (the author, Laura Kalbag, also wrote a book on accessibility)
- Plyr.io video player https://plyr.io/
- WebAxe (which is Lembree’s blog and podcast) has an article about video players. At the bottom he links out to some do-it-yourself resources.
- 3PlayMedia, a vendor, posted a summary of their webinar about “The Future of Video Player Accessibility” (from 2015). This is a biased source, but they do talk a bit about some of the issues being faced and the tradeoffs being made.
- The BBC in their style guide discusses audio and video players. At the bottom they have a testing checklist that illuminates some of the things that need to be true for a video to be accessible.
Stuff that I haven’t had time to sort.
- Designing systematic colors: How to make themable, flexible, WCAG 2.1 compliant color ramps for a design system. Jeeyoung Jung. 2018, March 27. UX Planet.
- Patrick Fox, tech director at Publicis.Sapient. slide presentation on : focus management, announcing dynamic content, modal dialogs, dynamic table filter and sorting. June 2018. http://www.pfox.io/accessu-widgets1.html
- part 2 of Patrick Fox, this one has wizard progress indicator, file selector & upload, form validation, search by location, improving single page applications. http://www.pfox.io/accessu-widgets2.html
- Heydon Pickering – cards – https://inclusive-components.design/cards/
- Marcy Sutton – empathy driven development – https://github.com/marcysutton/empathy-driven-development
- Static AST checker for accessibility rules on JSX elements.
- Why? Ryan Florence built out this awesome runtime-analysis tool called react-a11y. It is super useful. However, since you’re probably already using linting in your project, this plugin comes for free and closer to the actual development process. Pairing this plugin with an editor lint plugin, you can bake accessibility standards into your application in real-time.
- Note: This project does not replace react-a11y, but can and should be used in conjunction with it. Static analysis tools cannot determine values of variables that are being placed in props before runtime, so linting will not fail if that value is undefined and/or does not pass the lint rule.