Systemwide Human Resources

This piece of advice may have the smallest cost to biggest benefit ratio of anything we do in accessibility: i.e., it’s really easy to verbally describe visuals in videos, but if we don’t, there’s a high resource cost to making those videos sufficiently accessible (as captured and described by WCAG SC 1.2.5 Audio Description (Prerecorded)).

Don’t rely on audience members’ ability to see visuals in order to follow along and understand the points you're making.

For example, if you’re giving a presentation or recording a lecture and you show the slide to the right…

It wouldn’t suffice to only say, “As you can see, disabilities are more common than you may think," because audience members who couldn’t see the slide details would be deprived access to the visual information that supports what you’re saying.

You would need to also say (in some way, shape or form), “According to CDC research, 26% of Americans overall, college aged and older, experience a disability; 5% have vision disabilities; 6% have hearing disabilities; 11% have cognitive disabilities; 14% have physical, motor, mobility disabilities.”

Videos, eCourse slides containing audio and other forms of “synchronized media” must be accompanied by captions.

Captions produced automatically, such as through YouTube or Zoom, are better than no captions at all, but to be fully compliant, captions must accurately reflect: A) what is being heard, including sound effects and music that provide important context; and B) the timing of when it is being heard.

Audio-only files — e.g., mp3s, podcasts, etc. — that are not synchronized with another format of presenting information need be accompanied by transcripts.

Learners may appreciate being offered transcripts even when captions are present, but it is not an accessibility requirement nor would it satisfy the accessibility requirement of the videos, eCourse slides containing audio and other forms of synchronized media needing to be captioned.

(While it is a ubiquitous practice within eLearning to only provide a transcript to accompany eCourse slide audio, WCAG SC 1.2.2 actually requires that all eCourse slide audio be captioned, since an eCourse would technically be considered synchronized media; its slide audio is synchronized with another format of presenting information — slide text and other slide contents.)

The UC Electronic Accessibility Committee website provides additional information on transcripts & captioning.

Non-decorative images are images that are intended to convey information.

Sometimes they do this explicitly; sometimes they do this implicitly, such as when images are intended to serve as visual metaphors (e.g., a stop sign image being displayed in a PowerPoint slide that describes how one should stop and do something).

Decorative images are those that either do not add any information — they're included solely to enhance the visual design — or they provide information that is already being provided through surrounding, such as the two reference images in the tip concerning reading order.

In Microsoft Office 365 products, right click an image and choose Edit Alt Text to open the Alt Text panel, in which you can assign alt text or mark the image as decorative. 

In HTML, use the alt=”alt text goes here” property for non-decorative images and alt=”” to mark decorative images as such.

As defined by WCAG, text can only be considered "pure decoration" (exempting it from certain accessibility requirements like contrast and audio descriptions), if it can be replaced or rearranged without that affecting the text's meaning or purpose.

In text documents (.doc, .docx, .txt and .rtf files, Google Docs, etc.) and in HTML environments, the order in which assistive technologies encounter and read content tends to match the order in which content is arranged on a page, so no “behind-the-scenes” re-ordering is necessary.

In PowerPoint, the order in which assistive technologies encounter and read content is determined by the order of elements in the Selection pane (accessed through the Format ribbon or Arrange drop menu).

Elements in the Selection pane are encountered/read bottom to top: as in, the element that is lowest in the Selection pane is the first element in the slide that assistive technologies will encounter/read; the element that is highest in the Selection pane is the last element in the slide that assistive technologies will encounter/read.

You may need to manually review, and possibly edit, the order of elements in each slide.

In PDFs, the order in which assistive technologies encounter and read content is determined by the order of tags in Adobe Acrobat Pro’s Tags pane. Note: the Tags pane is not available in Adobe Acrobat Reader; contact your location’s IT Services if you need Adobe Acrobat Pro.

The Tags pane is read top to bottom: as in, elements that are higher in the Tags pane will be encountered and read before elements that are lower in the Tags pane.

You may need to manually review and edit the order of elements in the Tags pane, especially if you did not actively manage reading order in the program used to produce the PDF.

Additionally, be aware, if you have Adobe Acrobat Pro’s Reading Order tool open, with the “Show page content groups” and “Page content order” settings assigned, the numbers you see within the PDF’s body DO NOT indicate reading order (they indicate Reflow order). Reading order is visible and editable only through the Tags pane.

Content that is packed too closely together can be difficult for users with certain disabilities to read and process (on top of being a source of friction for all audiences).

Explore Working with Large Amounts of Text for tips on how to better space and "chunk" text, so it's easier to read and less intimidating.

Do not use tables for layout purposes: that is, do not use tables for the purpose of achieving a specific visual design. Tables should only be used to present tabular data or information. Further below is an example of a table being used (inappropriately) for layout purposes, along with an informal test you can use for assessing if you're using tables properly or not.

Making tables with merged/spanned cells accessible can be a challenge — it can't be done natively in Microsoft Word and it requires additional work and expertise in PDF and HTML environments — so unless you're experienced with doing that work, it's generally recommended that you avoid using merged or spanned cells in tables..

A table's first row is commonly used to label what is in each column, and similarly, the first column is often used to label what is in each row. Program these "label cells" in the first row and/or column as table header cells; doing so will provide screen reader users with incredibly useful reminders of what each cell's data or information represents.

In Microsoft Office products, use the Header Row or Repeat as Header Row table settings to program a table's first row as table header cells; use the First Column table setting to program a table's first column as table header cells.

In HTML environments, follow the detailed creating accessible tables guidance provided by WebAIM.com.

Table for Layout Purposes and the 3c's Test

The table above is being used (inappropriately) for the purpose of achieving a newspaper-like visual design, not for the purpose of presenting tabular data or information.

The 3c's test can help you assess whether you're using tables appropriately or not. The 3c's are: comparing and/or connecting, consistently.

If you're using table structure to compare and/or connect data/information in each row and/or column AND you're doing so with absolute consistency — e.g., the same number of cells in each column and row; the same type of data/information in each column and/or row; the same order of data/information in each column and/or row — then you're probably using the table appropriately, to present tabular data or information.

But if you're not using table structure to compare and/or connect data/information OR you're doing so without sufficient consistency, then you're probably using a table for layout purposes or introducing another table accessibility issue.

The example table further above fails the 3c's test because:

It isn't using table structure to compare data/information.

And it isn't using table structure to connect information (we can tell because each cell's contents are arbitrarily determined by what fits in the cell, rather than a purposeful attempt to connect specific pieces of information), so it already fails the 3c's test.

And there is no consistency in terms of what is in each column and row, so it fails the 3c's test in that regard as well: there are a different number of cells in different columns; there are different parts of each article in each column; and related to that, there is a different order of article parts in each row.

When it comes to assessing color contrast, there are three types of content:

• "Large text" is any text that is:
  • At least 14pt in size and bold
  • At least 18pt in size
• "Normal text" is any text that is not large text
• "Graphical elements" are things like icons, buttons, sliders and other interface controls

Use a contrast checker tool to:

• Identify the contrast ratio between foreground and background color pairs
• Determine if that ratio is sufficient for the content type
  • If a contrast checker tool you're using does not indicate pass/fail for graphical elements, refer to the the pass/fail indicator for large text, since that content type requires the same contrast ratio as graphical elements (3:1)
• (If necessary) Find lighter or darker color variants that will allow a color pairing to achieve sufficient contrast

You can use color to convey information, but you need to use it in combination with something else that conveys the same information — e.g., text, an icon, etc. — so that individuals who have difficulty perceiving color have a means for receiving the information.

Link text is quite simply text that hosts a hyperlink. For example, "Word-to-PDF and PDF Accessibility Guide (pdf)" further below serves as link text.

For a link to be accessible, users need to able to determine its purpose and/or destination from its link text alone.

Do not use "click here" or other generic phrases as link text, as they do not, on their own, allow users to determine a link's purpose and/or destination.

No two links in the same environment should use the same exact link text unless they direct to the same exact destination.

When linking to files, include the file type at the end of the link text. For example, Word-to-PDF and PDF Accessibility Guide (pdf).

Avoid using URLs as link text — they tend to be long and often do a poor job of describing the link — EXCEPT in situations where users will only see a link and will not have the ability to click on and open it, so providing the full URL is necessary for users to have any sense of the link's destination: e.g., in printed materials or in audio/visual presentations like lectures and webinars.

Introducing sections with headings helps all users find specific information within an environment, and it helps assistive technology users more easily navigate digital environments.

In Microsoft Word, use the heading Styles, available in the Home ribbon, to program individual headings.

In Rich Text Editors, use the heading styles in the Format > Headings, Paragraph Styles or equivalent menu.

In HTML and PDFs, use heading tags — <h#>, where # is the heading's level — to program individual headings.

A proper heading hierarchy accurately communicates the parent, child, peer relationships between headings and the sections they introduce. Think of it like an outline or a bullet list that uses different degrees of indentation to convey relationships:

• Heading 1 is the highest level; it's typically recommended that a document's or web page's title be programmed as the only heading 1 in the environment (because the title typically describes the entire environment and logically, nothing within the environment could be a peer of the environment itself)
  • Heading 2's introduce main sections within the environment
    • Heading 3's introduce sub-sections within main sections
      • Heading 4's introduce sub-sections within sub-sections, and so on...

Certain text properties make text more difficult to read and interpret, especially for users who have dyslexia and other disabilities.

Font styles

Underline: the underline font style can make it more difficult to differentiate letters and other text characters/symbols. Additionally, underlining only link text makes link text easier to spot and provides a means other than color for differentiating link text from non-link text. For these reasons, the underline style should be reserved for link text and certain citations.

Bold, italics, all caps and small caps: these font styles can, to different degrees, also make it more difficult to differentiate letters and other characters/symbols. For this reason, all caps and small caps should be avoided; italics and bold should be used sparingly and purposefully, to emphasis only short segments of text, with bold being preferable to italics, as appropriate.

Decorative fonts can also enhance reading difficulty and should generally be avoided.

Text alignment

Left-aligned text is generally easiest to read for all users, including those who have disabilities.

Center-aligned, right-aligned and justified text alignment can enhance reading difficulty, especially for users who have disabilities, and should generally be avoided, especially for larger blocks of text (i.e., more than a few lines of text).

Assistive technologies need to be able to interpret the same “structure” that is seen visually. For example, if you have a bit of content that appears visually as a three-item list, it needs to be programmed in a way that allows assistive technologies to interpret it as a three-item list.

How to successfully program all types of content in all types of environments (Word documents, PDFs, HTML, etc.) is too expansive a topic for this page and is better left to resources like the Word-to-PDF and PDF Accessibility Guide (pdf), but a good first step in that direction is to use typesetting features for their intended and stated purposes.

For instance:

If you want to program lists (in Word, in PowerPoint, in Rich Text Editors, etc.), use the provided bullet list or numbered list features; don’t just manually type a dash, number or letter to create the appearance of a list item, because assistive technologies won't be able to recognize that structure.

If you want to program headings in Word, use the heading Styles available in the Home ribbon; don’t just use font settings (size, bold/underline/italics, color, etc.) to make certain bits of text appear as if they’re headings.

If you want to program image alt text, find and use the program's alt text feature.

Etc.

For a digital product or environment to be accessible, users must be able to access and engage with all of its interactive controls using only their keyboards; use of a mouse should not be necessary.

This is something most of us can test on our own using a few basic keyboard commands:

• Use the Tab key to cycle focus forward
  • "Focus" is essentially the keyboard's cursor; it's indicated by a highlight on or around whatever interactive element currently has focus
  • In most products/environments, only interactive elements can receive keyboard focus
• Use the Shift+Tab keys together to cycle focus backward
• Use the arrow up/down keys to navigate certain menus and button sets, and to scroll pages up/down
• Use the Enter or Space keys to interact with something that has focus

When doing this testing, ensure that all interactive elements can receive focus AND that they receive focus in the order that best facilitates comprehension and engagement.

In some cases, an interactive element's inability to receive focus could signal other issues. For example, if a link within a PDF cannot receive focus, it won't be accessible to screen reader users and probably won't even work for mouse users.