BTP Accessibility Guidelines and Resources

Summary

Accessibility is a critical frontier for web development that is often underserved and overlooked. It is both morally correct and financially worthwhile to implement accessibility features to the best of our abilities. Building accessible software helps shield our clients from lawsuits (for instance, for federal agencies, via Section 508 compliance), improves the reach of their content, improves SEO performance, and consequently, generates more revenue.

The aim of this document is to identify which aspects of our software and design processes we can improve in terms of accessibility, as well as to serve as a resource for guidelines and considerations.

However, accessibility-prioritized work does come at an additional developmental and quality assurance testing cost. Therefore, we should leverage the many tools at our disposal to use the correct semantic, functional elements where possible, and where not, create consistent, bullet-proof standards from which we can base our work. This should reduce the amount of overhead involved in implementing these accessible features time and again. Additionally, by “shifting left” on the accessibility aspect of our work, we should see mistakes occur earlier in development and thus address them earlier.

Underpinning any attempt to make web content accessible is the need to understand what accessibility features are required to serve most audiences. Because accessibility is a moving target, we need to define the conceptual framework for what makes something accessible. Then, with this framework in mind, we can seek design and code solutions. You will often hear these concepts referred to by an acronym: “POUR.”

Table of Contents

The Four Pillars of Accessibility (“POUR”)

• Perceivable and Understandable
  • The accessibility of the content itself and its specificities, verbiage, and formatting. Is it properly labeled? Is it in the correct language? Does it make logical sense and is it ordered correctly?
  • The visual and aural presentation of the content that must be made accessible. Do videos have captions, do sounds have descriptions? Can a colorblind person read the text?
• Operable and Robust
  • The functionality required to expose the content and interactivity to accessibility software (“screen readers”) such as JAWS. Does a button indicate that its dropdown is toggled?
  • Coverage across a myriad of user agents and tooling. Can it work on older browsers? What about tablets, mobile devices?
  • Consistent across your application/site’s experience. Do you follow conventions and design patterns that are well established?

The Absolute Minimum

Taking the POUR framework into account, 18F (a now-defunct governmental organization that defined web standards for governmental tools such as the IRS website) had a ranking system for the "absolute minimum" standards for Section 508 accessibility compliance. Ranked from most to least critical, they are as follows:

A – Critical

1. Site is keyboard accessible
   • All pointer interactions can be accessed with a keyboard
2. Site is free of keyboard traps
   • The keyboard focus is never trapped in a loop
3. All form inputs have explicit labels
4. All relevant images use an img tag
   • Relevant here meaning the image contributes meaning that isn’t otherwise communicated primarily by textual/aural/visual content.
   • Background images that provide mere decoration, for instance, do not need to be image tags, though it should be considered anyways for caching, lazyloading, and reactivity.
5. All (relevant) images have non-empty alt attributes
6. Multimedia is tagged
   • All multimedia has appropriate captioning and audio description where available
7. Text has sufficient color contrast
   • All text has a contrast ratio of 4.5:1 with the background

B – Less Critical

1. Site never loses focus
   • Focus is always visible when moving through the page with the keyboard
2. Tab order is logical
3. Form instructions are associated with inputs
4. Site doesn’t timeout unexpectedly
   • Identify elements that may “timeout” and verify that the user can request more time
5. Tables are coded properly
   • Tables have proper headers and column attributes
6. Headings are nested properly
   • Heading elements are nested in a logical way

C – Minor

1. Frames are named
   • All frames have a name element
2. Flashing elements are compliant
   • Elements that flash on screen do so at a rate of less than 3 Hz
3. Language is set
   • The language for the page is set
   • The language for sections on the page that differ from the site language are set
4. CSS is not required to use the page
   • The page makes sense with or without CSS
5. Links are unique and contextual
   • All links can be understood taken alone, e.g., “Read more – about 508”
6. Page titles are descriptive
7. Required plugins are linked on the page

Design Guidelines

Finding a balance between elegant, beautiful design and accessible content can be challenging, and therefore some guidelines with varying degrees of necessity should be established. Critically important aspects have been labeled with the keyword “MUST.” General good practices are typically labeled “SHOULD.”

Text (Typography)

• The minimum font-size for any perceivable content MUST be no less than 9pt (12px).
• The design SHOULD support zooming (magnifying) the font-size up to 200% without breaking the layout or functionality.
• You SHOULD NOT use optical font technologies, salting, and anti-aliasing. These can interfere with legibility on user-defined typefaces.
• All-caps SHOULD be used sparingly.
• Lower font weights demand greater contrast for legibility, achieved either through size or color relationships.
• Ensure that line-spacing (leading) is at least 1.

Interactive Elements (Buttons, Links, Inputs)

• All interactive elements MUST have a clearly delineated focus state. This may or may not differ from the hover state, which also MUST have a clear hover state.
• You SHOULD leverage the pointer cursor to indicate interactivity on hover.
• Interactive elements SHOULD have additional padding or a “dead zone” to improve clickability. This is especially important for people with motor disabilities.
• Links MUST be clearly differentiated from text, both with color/value and underlining.
• You SHOULD NOT use opacity alone to indicate a disabled state.

Animations and Transitions

• Flashing animations MUST NOT flash more than 5 times per second (12hz on a 60hz monitor). This is a serious epilepsy hazard.
• Animations such as fade-ins on scroll SHOULD only occur once per element.
• You SHOULD NOT animate or change the X/Y coordinates of an interactive element when hovering over it with a cursor. Scaling up or down visually is fine, moving it away from or decreasing the interactive zone’s size is not.
• Contrast between states should be granular and SHOULD NOT rapidly shift.

Color and Value

• Perceivable content (text and images) and interactive content MUST have a sufficient contrast ratio to be easily perceptible from other types of content. You can find a breakdown of the different suggested WCAG ratios here.
• Colors and value alone are rarely enough to distinguish interactive elements from content. Consider plussing your interactivity wherever possible with underlines, borders, spacing, placement, etc.

Design Patterns

• Modals SHOULD isolate themselves visually from the context of the rest of the page.
• You SHOULD NOT nest modals within themselves (i.e. for a confirmation window on saving data in a form modal) as this can be both programmatically challenging and also confusing for screen readers. You can leverage the browser confirmation window for this if necessary.
• Where possible, interactive elements SHOULD have an associated text label. This can sometimes be avoided programmatically via aria-label, on a hamburger menu for example.
• When a pattern is established, follow it religiously. Things that behave as buttons should look like buttons, links should look like links. This reduces cognitive load for end-users.
• Group related functions together logically to aid people with tunnel vision.

Content

• You SHOULD try to keep maximum line length no longer than 80–120 characters. This helps with legibility for people who have difficulty following long lines horizontally.
• Paragraphs SHOULD have a significant (at least 1 line height) gap every 4–5 sentences.

Developer Guidelines

Incorrect ARIA/accessibility functionality is worse than no ARIA. By reducing the amount of JavaScript and complex functionality handled client-side, you also reduce the risk of serving a broken application to your end users. Therefore, it is important to leverage the functionalities native to browsers wherever possible, and to consider custom implementations with great caution.

Many web browsers have support for viewing the “accessibility tree” of a document and this feature should be used to verify the relationships between your content and interactive elements. It can help you find unlabeled items, interactive elements lacking events or states, and can also be useful for discovering things you do not want to expose to screen readers (e.g. decorative elements).

Semantics

• Wherever possible, you SHOULD prefer using semantic elements in favor of custom solutions, as they are guaranteed to have better screen reader support and cross-browser compatibility.
• When not possible, you MUST indicate the correct ARIA relationships between the element and the content or functionality it represents. This will often require the use of JavaScript. When in doubt, refer to the WCAG guidelines.

Interactive Elements (Buttons, Links, Inputs)

• You MUST use <a> tags for any functionality that changes the window location. In Vue, for example, this might be accomplished with the built-in <router-link> component, which unwraps into an <a> tag.
• Buttons without text labels (e.g. hamburger icon) MUST have an aria-label or aria-labelledby property indicating their function (aria-label="Open Mobile Menu").
• All inputs MUST be visibly labeled or aria-labeled. Using a placeholder as labels is not enough. Prefer the <label> element wherever possible.
• Forms MUST also be labeled in this way, however <label> is only for form controls. For visual labeling of forms, prefer using the sequentially correct heading element.
• All interactive elements MUST be keyboard accessible in some way. This does not necessarily mean tab-accessible, as some component patterns aim to reduce the amount of tabbing a user has to do to access things like nested lists.
• Visually hidden interactive elements (such as a closed mobile menu) MUST NOT be keyboard accessible until summoned/visible.
• In general, all users SHOULD be able to palpate the same content.
• You SHOULD provide instructions for complex user interactions where things like modifier keys are to be pressed in conjunction with another key.
• Unless design specifies otherwise, you SHOULD NOT overwrite the default :focus-visible state.
• In 99% of cases, you SHOULD NOT change the tab order of your interactive elements on a page.
• Interactivity SHOULD NOT have a timed component where possible. If required, it SHOULD have an option to elongate the interactivity window for users.
• There MUST NOT be any “focus traps” where a user is stuck in a loop when tabbing through your site’s content.

Animations and Transitions

• Autoplay should be disabled on uncontrolled (external) content like YouTube videos.
• All functionalities MUST work with animations and transitions disabled. Fade-ins should be at 100% opacity when scrolled, for instance.

Content

• Headings MUST always occur in logical order. You can have the appearance of one header replace the appearance of another, but the actual level must be linear. For example, do not start a page with an <h2> or skip from <h1> to <h5>.
• All palpable images should have specific, descriptive alt-descriptions.
• Breaking words up over multiple containers can sometimes affect the legibility of the content for some screen readers. Always verify legibility with a real screen reader or the accessibility tree viewer in your browser.
• You SHOULD NOT use <b>, or <i> at all. Prefer <strong> for importance and <em> for stressing a relationship. Use styled <span>s for stylization of text without semantic meaning.
• Text SHOULD always be real text leaf elements and not an image or an SVG element if possible.
• You SHOULD hide decorative-only elements (for instance, a chevron SVG on a correctly labeled dropdown button) from screen readers.
• Lists SHOULD be labeled or have a DOM-proximal heading.

Useful Tools and Testing

There are a variety of self-help developmental tools you can utilize to improve the accessibility of your website or app. While there is no true substitute for testing directly with assistive technology and polling your audience for their preferences and accessibility “stack,” these tools should aid in your workflow.

• Google Lighthouse (Chrome)
  • A built-in tool to enable developers to statically audit their pages for SEO, performance, and accessibility issues. Can help identify contrast issues, improperly labeled elements, etc.
• JAWS (Windows)
  • The most commonly used screen reader technology in the world. Gold standard for accessibility testing.
• VoiceOver (macOS)
  • Built into most Apple ecosystem products, the go-to screen reader for Apple devices.
• WAVE by WebAIM (Chrome, Firefox, Edge)
  • Adds a toolbar that automatically scans the current web page for ARIA errors, heading level issues, WCAG compliance and more.
• axeDevtools (Chrome)
  • Similar to WAVE but with a different UX and automated testing tools for tables and interactivity.
• HeadingsMap (Chrome)
  • Adds a toolbar for mapping headings and identifying unlabeled sections.

Auditing Services

Another option for accessibility maintenance and compliance is enlisting the services of an external auditing agency. These agencies tend to offer a few different types of compliance assurance, including testing, development, and ongoing maintenance. For legally precarious projects where Section 508 compliance or VPAT are required, using an external auditing service should be strongly considered.

• DigitalA11y
  • DigitalA11y has participated in the creation of many standards and documentation surrounding the topic of web accessibility.
  • Offers on-going support in addition to one-time audits.
  • Has development resources to assist in fixing discovered issues.
• Allyant
  • Offers auditing for complex applications in addition to typical websites.
  • Have experience working with large platforms such as WooCommerce, Adobe, and Shopify.
  • Also provides accessibility compliance testing for VPAT and non-web documents such as PDFs.