Accessibility - DOI-ONRR/nrrd GitHub Wiki

Accessibility

Introduction

Section 508 of the Rehabilitation Act requires that government Information and Communication Technology (ICT) be usable by people with disabilities. This includes websites. Section 508 specifically lists WCAG 2.0 (Web Content Accessibility Guidelines) issued by the World Wide Web Consortium (W3C) as the required standard for compliance. On ODDD, we not only do everything we can to meet Section 508 compliance, but we also incorporate best practices that go beyond the compliance standards. Whenever possible, we aim for the most up-to-date version of WCAG at the AAA level (currently version 2.2).

We also follow the five design principles of USWDS (United States Web Design System), one of which is Embrace Accessibility. The USWDS web pages for Embrace Accessibility and How to Use USWDS-Accessibility provide more detailed information and additional resources on why this is important in general and in our work as a government agency.

To test our designs, content, and code, we use a combination of automated and manual testing tools and methods. In this wiki, we only include the rules and best practices for accessible design and development that apply to ODDD's work. We don’t produce or post audio or video, and we don’t have auto-updating content on our sites.

When working on problems that address 508, WCAG, or accessibility best practices, use the "Accessibility" and "Enhancement" labels for your Github issues.

Resources

Table of Contents

Alt-text

Alt-text (aka alternative text) is text equivalent for a static image that is read aloud by screen readers.

A common misconception is that all images need thorough alt-text that includes all words that are in the image. Unfortunately, it’s not that simple.

Meaningful versus decorative images

The majority of images on onrr.gov and revenuedata.doi.gov are decorative. They do not provide the user with any information or context – they only add to the aesthetics of the page or provide visual cues that are duplicated with text (such as icons or the use of color in a chart key). Adding descriptive alt-text for non-meaningful (decorative) images does not just make more work for those using screen readers, but it actually violates Section 508.

For non-meaningful, decorative images, enter “” as the alt-text.

Avoid using the word “decorative” or using Aria labels to indicate the image is decorative. These two methods can be compliant but are not compatible with all assistive technology.

Images with text

The alt text will need to duplicate all of the text and information found in the image only if the text in the image is not anywhere else on the page and all the text is needed for the user.

However, many images either duplicate text found elsewhere on the page or provide more information than the user needs. In this case, there are options for simpler alt-text.

If the image duplicates text or information found elsewhere on the page, use the alt text to refer to the text instead of duplicating it. Example: “Refer to the text for more detailed information.”

Charts and graphs

Many of our charts, graphs, and data visualizations are interactive and change regularly as we get updated data. Here’s how to format the alt-text for these visualizations:

“Chart type of type of data where reason for including chart”

You also need to include a link to the data on the page, preferably in the chart caption or nearby text.

And make sure the linked data set meets accessibility requirements.

Resources

Logos

Logos are considered meaningful and need alt-text. The alt text must include the organization name, the work logo, and any other text in the logo. Do not describe the color or any other attributes in the logo.

Examples:

  • ONRR: Office of Natural Resources Revenue logo
  • U.S. Department of the Interior logo. March 3, 1849

Equations

Not all screen reading software read all signs and symbols correctly, so it is important to write out the word for symbols used in an image (eg. equals, squared, divided by).

Resources

Alt-text versus image description

Alt-text is concise and provides only what the user needs to put the image into context. On the other hand, an image description can be longer, go into more detail, and provide information beyond what is absolutely necessary for the user. Images marked as decorative in the alt-text might have an image description that tell the user what’s in the image. Image descriptions can also be used to enhance SEO. Image descriptions are not required for accessibility but can be helpful for all users. If you use image descriptions, do not duplicate what is in the alt-text – be intentional with the application of image descriptions.

Color and contrast

Color is crucial for accessibility because it helps ensure that information, products, and environments are inclusive to all individuals, regardless of their visual abilities. People with color vision deficiencies or color blindness may have trouble with certain color combinations, making it hard for them to see important details.

We can improve accessibility by using color schemes that provide enough contrast between elements like text, buttons, and interactive elements.

Color can also convey meaning and information, making data visualizations and charts more understandable. It's important to emphasize color contrast and provide alternative visual cues such as patterns so that people with different visual abilities can access and engage with content and information.

Color alone should not be the only way of conveying information or distinguishing elements. For example, links should not rely solely on color to be identified; they should also have sufficient contrast with the surrounding text and a visual cue on hover or focus, such as underlining.

For regular text and images of text, the minimum contrast ratio should be at least 4.5:1. For larger text (18pt or 14pt bold), the minimum contrast ratio can be lower, at 3:1. User interface components, such as icons and other essential graphics, should have a minimum contrast ratio of 3:1 against adjacent colors or backgrounds.

There are exceptions for certain types of text, like pure decoration, logos, or text not visible to anyone, which don't need to meet contrast requirements.

Resources

Content structure

Headings

Headings are used to separate parts of the web page into sections that logically and visually make sense to the user. Headings must be tagged correctly in the code – this is done using the headings option in the CMS for onrr.gov or markdown for NRRD and the blog. Do not use regular text with bolded or increased font size to represent headings. And vice versa – do not use headings for aesthetic reasons. Only use headings to indicate sections of a page.

Headings can also be indicated using Aria labels, but best practice is to use heading tags.

Headings must be nested in order. All pages should have at least an H1. Subsections then go in sequence: H2, H3, H4, etc. While it is okay to skip heading levels, it is best practice to avoid doing so when possible. For example: H1, H2, H4 is okay since it maintains the proper sequential order, but H1, H2, H3 is better. H1, H4, H3 is not compliant.

Heading levels must also provide visual cues to the user. As the heading level increases, the size or weight of the font must decrease. Headings must also look visually distinct from non-headings. Expansion panels (accordion menus) and tab titles must be tagged as headings. For tables, cards, and other types of content, consider if a heading or a programmatic title is more appropriate.

Acceptable example:

Example of correctly nested headings showing H1, H2, H2, H3, H4, H4, H2, H3, H3

Lists

  • Use different types of lists to group information according to its nature to provide orientation for users.
  • Unordered lists are used when the order of the items is not relevant. List items in unordered lists are marked with a bullet.
  • Ordered lists are used for sequential information and are automatically enumerated by the browser.
  • Description lists are groups of related terms and descriptions which are connected programmatically.
  • Individual list items can contain a variety of HTML elements, including paragraphs, headings, form elements, and other (nested) lists.

Resources

Tables

Tables take extra work to make accessible, but it is possible!

There are two kinds of tables: data tables and layout tables.

Layout tables are used to organize pieces of information visually and do not need row or column headers. Layout tables must be tagged as such – they must not be tagged as data tables.

Data tables require column and/or row headers to make sense of the information in each cell.

  • Header rows and columns must be coded as header rows and columns.
  • As a keyboard or screen reader moves through the table, the output for each cell must include the column and/or row heading as necessary, followed by the cell content.
  • Every data table needs a programmatically associated title. An unassociated title added as a heading or text might provide a visual cue but does not qualify as the programmatic table title.

Data visualizations

Creating accessible data visualizations means designing charts, graphs, and other visual representations of information in a way that is easy for everyone to understand. Accessibility ensures that data can be conveyed effectively to all users, regardless of their abilities or assistive technologies they may use. To achieve this, we consider factors like color contrast and object contrast and convey meaning not using only color. We use readable font size and descriptive labels. We add a data table or source data for an alternate format. We provide alternative text (alt-text) descriptions for images because for people using screen readers, these descriptions are essential for comprehending the visual content. Additionally, interactive elements should be operable using a keyboard, making it accessible to those who do not use a mouse.

Resources

Documents

Try not to publish content in the form of PDF files if there's an alternative. The content in PDF documents is not predictably structured, since they can be generated from multiple source documents using various software. PDFs comprised of scanned pages are not accessible, unless they have been processed with text recognition. When it is necessary to publish an electronic document, such as a PDF, on onrr.gov, it must be compliant with Section 508 of the Rehabilitation Act.

If you are submitting electronic documents (PDFs, Word documents, Excel spreadsheets, or PowerPoint presentations, etc.) to be posted on ONRR.gov, they must be accessible, or we will not post them online. These resources can help you create accessible documents and audit your documents for accessibility errors.

Training and guidance

Checking your documents

Language

Plain language

We adhere to the principle of plain language. Once your content is written, use Hemingway Editor or Microsoft Editor to get the content down to grade 10 if possible (sometimes it’s necessary to use industry, legal, or policy terms that make getting down to grade 10 impossible). More details about how we use Plain Language can be found in the Content Style Guide.

Relative position

Do not use language that refers to relative position on the page. For example, do not use statements such as: “Use the navigation on the left.” This means nothing to users with screen readers.

The exception is referring to items or content as “below.” This is acceptable only when what "below” is referring to is the very next thing on the page, as in this case “below” is considered synonymous with “next.”

Acceptable example: “To learn more, review the list of articles below:”

Link labels

  • Link labels should accurately and distinctly describe what the link target is.
  • Do not use the same link label for different targets on the same page.
  • Avoid using different link labels on the same page that go to the same target.
  • If the targets are anchored links for different parts of page, then it’s okay to have different link labels.
  • Do not use the word “here” in a link label. This is disorienting for screen readers. Such as “click here to access.”
  • Do not use ableist language in the link label or the text surrounding it.
    • Words to avoid: see, click, view, read, talk, speak, display
    • Acceptable words: learn, find, review, access, contact, open

Navigation

Keyboard access

Keyboard accessibility is about making sure that people can navigate and use all features of a website using only a keyboard. By doing this this, people can also use speech input, a mouse, and other assistive technologies to use the website.

Resources

Visible focus

Visible focus refers to the way in which a link or button has a visible change when those using keyboard navigation land on it. Visible focus is often achieved with an outline or a change in color or hue.

All elements that are interactive (such as links, buttons, filters, menu items, etc.) must have visible focus for keyboard navigation.

Visible focus for mouse navigation is best practice (interactive elements have visible focus when you hover over them), although not required for Section 508 compliance.