Front-End Developer

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:

Other good resources:

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.

Atomic Design

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

The Accessible Rich Internet Applications Suite (ARIA) defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Working with ARIA can be tricky.

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

The W3C ARIA 1.1 specification can be a lot to get through.  The W3C’s ARIA practices provides a better “what do I need to do” overview. MDN counterpart to the ARIA practices.

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 page with the allowed ARIA roles, states, and properties.

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.

A GitHub documentation page explaining how to make React.js (the JavaScript framework) more accessible. Covers a lot of the same ground as elsewhere, but the specific code examples can be helpful.

General Advice

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’).

Frameworks

Content Management Systems

WordPress best practices.

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.”

Alt Text

Here are some resources for deciding when and how to apply alt text to images.

Autocomplete (or Autosuggest)

Breadcrumbs

Here are some resources on creating accessible breadcrumbs for navigation.

Buttons

“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).

A11y Style Guide advice on Buttons

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

Short answer: You have to use JavaScript to compensate for a bug in Internet Explorer.

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.

Carousels

“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

Dialog Window

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).

Duplicate IDs

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

Focus Indicators

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.

Forms

Joshua’s question:

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.

Headings

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.

Hyperlinks

See Links.

Language

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.

Level Access video on screen reader language support (1 minute 18 seconds).

Landmarks

See Bypass Blocks and Landmarks

Links

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).

Lists

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.

Loading Spinner

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

Mega Menu

Level Access article (2018 February 9) on the challenges of making a mega menu accessible.

Modal

See Dialog Window.

PDFs

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.

Section Elements

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:
    …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. 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:
    …page content
  • 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.
    • 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
        element.
      • 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.

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
    :

    …nav elements
  • Any Navigation used on an Individual Page: Add a role to the appropriate
    :

    …nav elements

    (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
    :

    …page content
  • Website Footer: Includes the footer navigation links, etc. Add a role to the appropriate
    :

    …page content

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

tag

compared to the

element.

Skip Navigation

See Bypass Blocks.

SVGs

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

Tab panels allow multiple blocks of content to share horizontal space, yet make only one panel at a time visible.

Tables

Videos

Unsorted

Stuff that I haven’t had time to sort.