Provide meaningful Alt text for images. This helps users who rely on assistive technology such as a screen reader to understand the meaning of the image. The screen reader will read out the ALT description to the user.

  • Example: <img src="../images/womens_history_month_hero_image.png" alt="View the 2019 Women's History Month Opening Ceremony">

Images that Have Meaning

  • Examples of descriptive/meaningful Alt text
    • <img src="../images/dem_hero_image.png" alt="About the Neighborhood Emergency Response Team">
    • <img src="../images/city_seal.png" alt="City and County of San Francisco">
  • Examples of non-descriptive Alt text:
    • <img src="../images/city_seal.png" alt="image of city logo">
    • <img src="../images/dem_hero_image.png" alt="em_hero_image.png">

Decorative Images

Decorative images that don’t present important content or text should have null/empty alt text. Or in the event that ALT text is redundant. Screen readers will ignore these images all together.

  • Example: <img src="../images/dem_hero_image.png" alt="">

General Guidelines

  • Here are some general guidelines to follow when providing Alt text. Alt text should:
    • Be succinct. Typically no more than a few words or a short sentence.
    • NOT be redundant or provide the same information as text within the context of the image.
    • NOT use the phrases "image of ..." or "graphic of ..." to describe the image. A screen reader already tells the user this information.
  • For complex diagrams, charts, maps and graphs a text based equivalent needs to be provided either within the context of the page, such as in an adjacent data table. The alternative text can also be provided by linking to a separate web page that provides the longer description of the complex image.

Additional Information on Writing Effective Alt Text
https://webaim.org/techniques/alttext/

Color Contrast Between Text and Background Color

  • Provide sufficient color contrast between foreground and background, text and background color.
  • The contrast ratio between text and background, using regular body text, should be at least 4.5:1.
  • Large-scale text (24 pixels or 18 pixels bolded) should have a contrast ratio of at least 3:1.
  • Test your contrast level using this color contrast checker for WCAG AA compliance https://webaim.org/resources/contrastchecker/


Color Contrast Between a) Link Text and Background Color and b) Link Text and Surrounding Body Text

  • There should be a contrast ratio of at least 4.5.1 between link text and background color. This applies to regular body text (or 3:1 for large text) .
  • There must be a 3.1 contrast ratio between link text and surrounding text.
  • Use this link contrast checker to test color contrasts for links https://webaim.org/resources/linkcontrastchecker/

Color Blindness

  • When designing for color blindness, make sure that colors are not your only method of conveying important information.
  • Use this filter to test web pages for color blindness https://www.toptal.com/designers/colorfilter/
  • If the purpose of posting the content is to communicate something about the colors in that image or web page, then it is important to provide some other way of understanding the information.

Page Structure and Headings

  • Create a logical reading order by using properly nested headings in your markup, <h1> <h2> <h3> <h4> <h5> <h6>.
  • Build the structure of the page using semantic markup. Markup that has meaning to browsers and screen readers. A web page should be able to stand on its own without the help of a style sheet.
  • Sighted users often scroll the page quickly and look for headings to get an idea of the structure and content of the page. Screen reader and other assistive technology users also have the ability to navigate web pages by heading structure, assuming true headings are used (as opposed to text that is styled to be big and/or bold). This means that the user can view a list of all of the headings on the page, or can read or jump by headings, or even navigate directly to top level headings (<h1>), next level headings (<h2>), third level headings (<h3>), and so on.
  • There should only be one <h1> heading per page and should be applied to the page title to indicate to the user that this is where the content area begins.
  • Headings should be structured in a hierarchical manner.

Provide Descriptive Headings and Labels

Help users understand what information is contained in Web pages and how that information is organized by providing descriptive headings.

When headings are clear and descriptive, users can find the information they seek more easily, and they can understand the relationships between different parts of the content more easily.

Descriptive labels help users identify specific components within the content.

Labels and headings do not need to be lengthy. A word, or even a single character, may suffice if it provides an appropriate cue to finding and navigating content.

Lists

  • HTML lists - <ul>, <ol>, and <dl> - also convey a hierarchical content structure.
  • Lists should be used to display actual list items. They should not be used for layout purposes.

Provide Skip to Main Content Link

Provide screen reader and keyboard only users with the ability to skip repetitive navigation menu links and go straight to the main content area.

  • Make sure a “skip to main content” link has been incorporated to all site pages.
  • The link also needs to be visible for sighted keyboard only users.
  • The link should be placed at the very top of the page and link to the beginning of the main content area.

Provide Sequential Navigation

Ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard.

This reduces confusion by letting users form a consistent mental model of the content.

For example, a screen reader user interacts with the programmatically determined reading order, while a sighted keyboard user interacts with the visual presentation of the Web page.

Make sure that the focus order makes sense to both of these users and does not appear to either of them to jump around randomly.

Create a logical tab order, for screen reader and sighted keyboard only users, through navigation menus, forms and data tables.

Provide Consistent Navigation

Ensure that any type of navigation that is repeated across multiple web pages occur in the same relative order each time they are repeated.

Ensuring that repeated components occur in the same order on each page of a site helps users become comfortable that they will able to predict where they can find things on each page.

This helps users with cognitive limitations, users with low vision, users with intellectual disabilities, and also those who are blind.

The purpose of data tables is to present tabular information in a grid, or matrix.

Someone that cannot see the table cannot make the visual association between data in the table and their appropriate row and/or column headers.

So proper markup must be used to make a programmatic association between elements within the table.

When the proper HTML markup is in place, screen reader users can navigate through data tables one cell at a time, and they will hear the column and row headers spoken to them.

General Table Guidelines

  • Provide table headings
  • Provide a table caption that describes the content in the table
  • Avoid using tables for layout purposes

Forms elements need to be accessible to both screen readers and keyboard-only users.

Screen reader users and keyboard only users typically navigate through a form using the TAB key, on the keyboard, to jump from form control to form control.

Forms Checklist and Overview

  • Notify users when form elements are required to complete.
  • Create a logical structure and tab order within forms.
  • Ensure that form related instructions do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.
  • Ensure that the purpose of a form input collecting information about the user can be programmatically determined, so that user agents can extract and present that information to the user without having them type in the info (autocomplete).
  • Ensure that form related alert and error messaging do not only rely on color to convey the information.
  • Ensure that keyboard only users and screen reader users who rely on using a keyboard are able to navigate, complete and submit forms.
  • Ensure that content does not "trap" keyboard focus within subsections of content on a Web page. For example when navigating to and away from a calendar widget/component.
  • Provide users with adequate time to complete and submit forms.
  • Provide sighted keyboard only users with a keyboard focus indicator to let them know which form element has keyboard focus. The keyboard focus indicator needs to provide adequate color contrast between foreground and background.
  • Ensure that entering data or selecting a form control has predictable effects.
  • Ensure that form components that have the same functionality within a set of web pages are identified consistently.
  • Provide users with a mechanism to initiate a change in form behavior and form submissions.
  • Make users aware of important changes in content that are not given focus, such as inline error messages.
  • Provide role, state and value information in connection with form elements in order to make functionality accessible to assistive technology.

Keyboard accessibility is one of the most important aspects of web accessibility. Many users with motor disabilities rely on only using a keyboard to access content. Screen reader users who are blind or vision impaired will also use the keyboard to access and interact with content. Here are some general best practices.

Users Should Have the Ability to Navigate Using Only the Keyboard

Natively-Accessible Keyboard Elements:

By default, users can navigate to links, buttons, and form controls with a keyboard. These elements are natively-accessible by using the following keystrokes.

  • Tab: Navigate to links and form controls.
  • Shift + Tab: Navigate backwards.
  • Enter: Activate links and buttons.
  • Spacebar: Activate checkboxes and buttons.
  • Arrow keys: Radio buttons, select/dropdown menus, sliders, tab panels, autocomplete, tree menus, etc.

Keystrokes Accessible Only Through a Screen Reader:

  • In addition to the natively-accessible keystrokes, screen reader users have many other keystrokes available to them to help them navigate through a webpage. For example they can use the “H” key to tab through all the headings on a page.

Landmarks and Roles

  • Break the web page into areas/regions and assign landmark roles. Use HTML 5 in combination with ARIA roles.
  • Assistive technologies such as screen readers provide shortcut keys to navigate through page elements that have been defined as landmarks/regions and roles, or to jump to specific structural elements (for instance, M for the main content), and/or provide a list of all structural elements in the document.
  • Screen readers provide a list of all landmarks/regions on a page and shortcut keys to navigate among them.
  • Screen reader users can also navigate by landmark role.

Best Practices

When possible, PDFs should be eliminated in favor of web pages because they do not work well on mobile devices and are challenging to navigate for people using assistive technology.

However, if you must publish your information in PDF format the content needs to be fully accessible to everyone.

Whenever we publish online content, we need to make sure everyone can read it, including keyboard only users and people using assistive technology such as a screen readers.

This is also true for PDF documents. Similar to directly coding content into a website, there are special steps we must take to make sure that a PDF can be read by assistive technology.

Issues with PDF Documents

  • Mobile Issues: Unlike web pages, PDF documents are not responsive and do not adjust to your screen size, such as on a mobile device. This forces the user to have to zoom in and the swipe left to right /right to left in order to read the content.
  • Difficulty Navigating Content: They are difficult for web users, including screen reader users, to navigate when seeking specific information. Because the website navigation menu doesn’t appear when viewing the file, users can become disoriented.
  • Language Barriers: Content within PDFs are not easily made available in different languages. Per the city’s Digital Accessibility and Inclusion Standards, you need to provide vital information in required languages.
  • Not Designed for Reading on Screen: PDFs are not really designed for reading on screens. They should mainly be used as a way to print information.
  • Maintenance and Outdated Information: PDF documents are more time consuming to update and maintain and as a result often times are overlooked and as a result information in PDF documents is more likely to be outdated.

Step-by-Step Guides

General Checklist and Guidelines

  1. Make sure the PDF is in a text based format.
  2. Create a logical reading order by providing a main heading and subheadings.
  3. Tag and build your document structure in Microsoft Word
    Apply properly nested headings <h1>, <h2>, <h3>, <h4>, <h5>, etc.
    The <h1> heading should be reserved for the document title
    Add paragraphs <p>
  4. Add ALT text (alternative text) for images.
  5. Complex charts and diagrams that are embedded in the PDF can’t be accessed by screen reader users. In these cases a text based equivalent needs to be provided. This could be a summary of what the chart/graphic is conveying to sighted users.
  6. Make sure there is sufficient color contrast between text and background.
  7. Ensure that content displayed in a data table is fully accessible to screen reader users.
  8. Provide a table of contents so it’s easy for users to find and navigate to information.
  9. Save your Word or PDF document as a tagged PDF.
  10. Provide meaningful document titles for screen reader users, using Adobe Acrobat Pro.
  11. Avoid writing important information in the document header or footer. Screen readers will not announce content displayed in the header and footer.
  12. Provide descriptive link text.
  13. Ensure that any interactive elements are fully accessible.
  14. Test your document in Microsoft Word or Adobe Acrobat for accessibility compliance.

How to create an accessible PDF using Microsoft Word

Step-by-step guide on how to create an accessible PDF using Microsoft Word

Appropriate font and size

  • Choose an easy to read font like Arial or Verdana
  • The font size should 12 pt or larger


Using color appropriately

  • Make sure there is enough contrast between the words and the background. For example, do not put light gray text on a medium gray background.
  • Never use color alone to convey important information. Some people have color vision problems which prevents them from distinguishing between certain colors.


Add alternative texts and captions to images


Specify Column Header Rows in Tables


Use Meaningful Hyperlink Text

  • Make sure your link text is more descriptive than “Click here” or “View”.


Use Built-in Formatting Styles

  • When adding headers to the document, utilize the various items in the Styles pane instead of manually enlarging and/or bolding text.
  • Make sure that the headings are in chronological order. For example, any headers directly below the Heading 1 section must be Heading 2. It must not skip directly from Heading 1 to Heading 3.
  • Include a table of contents for long documents
  • Use the bulleted or number list buttons to format lists


Check accessibility


Save the Word document as a PDF


Additional resources

Make audio and video related content fully accessible to vision and hearing impaired users.

Video Content with Audio (prerecorded)

Users who are deaf, hard of hearing, or having trouble understanding the audio information must be provided with a text based alternative.

Captioning should be provided for the audio portion of a video.

The captioning must be synchronized with the audio so that someone reading the captions could also watch the speaker and associate relevant body language with the speech.

Audio-Only Content with No Video

Audio files with no video are not considered multimedia. However, since audio is a non-text element one of the following text-equivalents must be provided for deaf or hearing impaired users.

  • HTML based transcript
  • Text transcript
  • A text or HTML summary


Provide a Description of the Visual Content in Videos (prerecorded)

Provide vision impaired users access to the visual information in a synchronized media presentation.

Alternative One

One approach is to provide audio description of the video content. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During existing pauses in dialogue, audio description provides information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.


Alternative Two

The second approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. An alternative for time-based media provides a running description of all that is going on in the synchronized media content.


Live Audio and Real Time Presentations

Provide hearing impaired users with synchronized captions for any live audio and real time presentations.


Flashes

Ensure that video related content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Allow users to access the full content of a site without inducing seizures due to photosensitivity.

Individuals who have photosensitive seizure disorders can have a seizure triggered by content that flashes at certain frequencies for more than a few flashes

General Writing Guidelines

Acronyms:

  • Whenever possible try and steer away from using acronyms and symbols. Screen readers try to pronounce acronyms, if there are sufficient vowels/consonants to be pronounceable. Otherwise, they will try to spell out the letters.
  • Spell out “OK” as “Oklahoma”. Screen readers will read out OK as “Oak”
  • Spell out “BR” as “Bedroom”.
  • Spell out months, instead of “Dec.” say “December”
  • Instead of “$75,000/year” say “$75,000 per year”
  • Instead of “1-3 people” say “1 to 3 people”
  • Instead of “9:00am - 12:00pm” say “9:00am to 12:00pm”
  • Instead of “(415) 444-8989” say “415-444-8989”


Links:

  • Ensure that all links are informative, and meaningful when read out of context. Link text should be a meaningful representation of the link target.
  • Screen-reader users may be unable to easily access contextual information related to a link.
  • Single word links represent small targets for persons who have difficulty controlling a pointing device due to motor impairments. Placing long lists of text-based links close together in rows or columns increases the probability of a mouse error.
  • Avoid the use of single word links (“Here”, “More”, “Go”). Links should be clear, descriptive and able to stand alone.
  • Avoid enclosing text links in brackets, braces, parentheses.
  • Avoid “Click Here”


How Screen Readers Read Content in General

  • Screen readers pause for:
    • periods
    • semi-colons
    • commas
    • question marks
    • exclamation points
    • paragraph endings
  • Screen readers read letters out loud as you type them, but say “star” or “asterisk” for password fields.
  • Screen readers announce the page title (the <title> element in the HTML markup) when first loading a web page.
  • Screen readers will read the alternative text of images, if alt text is present. JAWS precedes the alternative text with the word “graphic.” If the image is a link, JAWS precedes the alternative text with “graphic link."
  • Screen readers ignore images without alternative text and say nothing, but users can set their preferences to read the file name.
  • If an image without alternative text is a link, screen readers will generally read the link destination (the href attribute in the HTML markup) or may read the image file name.
  • Screen readers will bypass images that have been marked as decorative image.
  • Screen readers announce headings and identify the heading level. NVDA and JAWS, for example, precede <h1> headings with “heading level 1.”
  • Some screen readers announce the number of links on a page as soon as the page finishes loading in the browser.
  • JAWS says “same page link” if the link destination is on the same page as the link itself and “visited link” for links that have been previously accessed.
  • Screen readers in table navigation mode inform the user how many rows and columns are in a data table.
  • Users can navigate in any direction from cell to cell in table navigation mode. If the table is marked up correctly, the screen reader will read the column and/or row heading as the user enters each new cell.
  • Screen readers inform users when they have entered into a form. Users have the option to enter form navigation mode.
  • Screen readers can be thrown off by homographs. For example, the word read can be pronounced “reed” or “red,” depending on the context: “I’m going to read the newspaper” vs. “I already read the newspaper.” A sentence such as “I read the newspaper every day” is ambiguous to all readers—humans and screen readers alike.
  • Screen readers may or may not read out punctuation, depending on the user’s verbosity setting. Ensure that your intended meaning will be conveyed in either case. To appreciate the value of punctuation, consider these sentences:
    • Let’s eat, grandpa!
    • I’d like to thank my parents, the mayor, and the president.
    • He finds inspiration in cooking, his children, and his cat.

Popups

Popups are not a good user experience for keyboard-only users and screen reader users and as a rule of thumb should be avoided.

When an automatic popup appears it does not by default have keyboard focus which means that keyboard only and screen reader users are unable to use the TAB key on the keyboard to immediately access the content within the popup and close the popup. Screen reader and keyboard-only users can easily become distracted and disoriented.

When a popup unexpectedly appears it does not have keyboard focus which means that screen reader users are unable to use the TAB key on the keyboard to navigate to the content within the popup. They cannot visually see the popup on the screen, unless it's automatically programmed to completely shift the focus away from the main window. However, this would be very disorienting to screen reader users.

Unexpected and automatic popup windows should not appear without warning or notification.

Users should be provided with a mechanism, such as a link or button, to activate a new window.

Ensure that keyboard focus is visible and not obscured when a new window is opened, so users can easily identify where they are within the content. Sighted keyboard only users navigate web pages by using the TAB key on the keyboard through actionable items such as links, buttons and form controls. They rely on keyboard focus indicators (a border or outline) to let them know what item has keyboard focus. Keyboard focus indicators cannot be obscured by a popup window.

New windows should not automatically be launched, and change context, when a component receives focus.

As a general rule of thumb slideshows and moving content should be avoided as it is not fully accessible to keyboard only users and screen reader users.

Users with disabilities should be given adequate time to interact with web content and should be provided with the ability to pause, stop and hide any moving content.

Slideshows and moving content that cannot be stopped and paused by keyboard only and screen reader users must be disabled.

Having something repeatedly moving across the screen is very distracting, especially for users with learning disabilities.

Any slideshow related content should not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Often times websites will feature content that is hosted or created by a third party vendor.

That content is frequently embedded to the web page via an iFrame.

Screen reader users rely on a frame title to describe the contents of the frame. Navigating through frame and iframe elements quickly becomes difficult and confusing for users of this technology if the markup does not contain a title attribute.

Screen reader users have the option to pull up a list of titles for all frames on a page. Adding descriptive, unique titles allows users to quickly find the frame they need. If no titles are present, navigating through frames can quickly become difficult and confusing. If no title is listed, screen readers will instead give information like “frame,” “JavaScript,” the filename, or the URL. In most cases, this information won’t be very helpful.

Provide screen reader users with a descriptive iFrame title attribute to indicate what type of information is available within the iFrame.

Example:

<iframe src="unemployment.htm" title="Interactive data showing unemployment rate in Oklahoma City">

Interactive PowerBI charts are typically embedded to a web page via an iFrame.

It's important that this data is fully accessible to both keyboard only and screen reader users.

Provide a text-based alternative or equivalent for interactive content that cannot be accessed by screen reader or keyboard only users. The text based equivalent (or a link to the text based equivalent) must be placed in close proximity to the interactive content.

Ensure that the content does not "trap" keyboard focus when navigating PowerBI charts and interactive maps. Keyboard only users and screen reader users must be provided with a mechanism (using only the keyboard) to exit the charts and interactive maps.

General Guidelines for PowerBI Charts

  • Add ALT text (alternative text) to graphics for screen reader users.
  • Provide keyboard only users with instructions on how to navigate and interact with the charts and dashboards. This would include instructions on specific keystrokes for users to press.
  • Provide keyboard only users and screen reader users with instructions on how to interact with the filters.
  • PowerBI charts often rely on using colors to convey data. However, screen reader users would not be able to pick up this type of information. Make sure that there is a text based equivalent.
  • For users with learning disabilities and users who find it challenging to interact with the PowerBI charts, please provide a text based equivalent of the raw data presented within the chart. The link to the text based equivalent should be placed in close proximity to the actual chart.
  • Ensure that all chart labels are displayed horizontally.
  • Ensure that there is enough color contrast between chart legends and chart graphs.

Guidelines for Interactive Maps

Here are some general guidelines to follow.

  • Keyboard only users, screen reader users and users with learning disabilities who are unable to interact with the map, must be provided with a text based equivalent of the raw data presented within the map.
  • The link to the text based equivalent should be placed in close proximity to the actual map.

5th Grade reading level

Provide vital information for the public at a 5th grade level.

In cases where technical or legal language is necessary, you must provide a summary at 5th grade level.

Hemingway App: Reviews reading level of written content and provides suggestions.

Unusual words

Provide users with a mechanism for identifying definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.

Abbreviations

Provide users with a mechanism for identifying the expanded meaning of abbreviations.

Pronunciation

Provide users with a mechanism for identifying pronunciation of words where their meaning is ambiguous.

Your website content must also be fully accessible on mobile devices, including users who rely on using a mobile screen reader.

iOS and Android mobile devices both have built in screen readers.

Mobile screen reader users use swiping and tapping gestures to navigate websites on mobile devices.

Mobile accessibility best practices

Following are some mobile accessibility best practices.

Provide easy tap/touch targets

Tap targets within an app should be big enough for people to interact with precision.

Touch targets should be at least 9 mm high by 9 mm wide. Mobile applications should also position interactive elements where they can be easily reached regardless of how the device is held.

Provide sufficient color contrast

Extra attention must be paid to mobile devices when it comes to color contrast.

Mobile devices are more likely to be used outdoors, where glare from the sun could impact ability to see the screen.

Text legibility should be preserved by an adequate contrast between the font color and the background.

For WCAG 2.1 AA compliance, text should have a color contrast ratio of at least 4.5:1 (larger text at least 3:1).

Allowing different contrast ratios for larger text is useful because wider character strokes are easier to read at a lower contrast than narrower character strokes.

Make it easy for users to enter data

Reduce the amount of text entry required by providing select menus, radio buttons, or check boxes, or by auto filling known information (e.g., date, time, location).

Create a logical reading/tap order for screen reader users

Create a logical reading/tap order for screen reader users.

Place submit buttons for forms, etc, in context of actions performed within the content area

The screen reader will read from top to bottom of the screen.

Provide users with the ability to display content in their preferred orientation

Ensure that content displays in the orientation (portrait or landscape) preferred by the user, including on a mobile device.

Provide users with the ability to control text size

Allow the user to control the text size on mobile devices with small screens.

Steer away from using PDF documents

Unlike web pages, PDF documents are not responsive and do not adjust to your screen size, such as on a mobile device. This forces the user to have to zoom in and the swipe left to right /right to left in order to read the content.

Keyboard related guidelines for touchscreen devices

Allow mobile devices to be operated by external physical keyboards or alternative on-screen keyboards.

Ensure that content accessed through a mobile device does not "trap" keyboard focus within subsections of content.

Ensure that when mobile keyboard users or mobile screen reader users navigate sequentially through content on a mobile device, they encounter information in an order that is consistent with the meaning of the content.

Help mobile keyboard users and mobile screen reader users know which element has the keyboard focus.

Navigation and consistency

Ensure that navigational mechanisms on a mobile screen, that are repeated on multiple web pages within a set of web pages, occur in the same relative order each time they are repeated.

Ensure that components viewed on a mobile device, that have the same functionality within a set of web pages, are identified consistently.

Links and grouping of operable elements that perform the same action

When multiple elements perform the same action or go to the same destination (e.g. link icon with link text), these should be contained within the same actionable element. This increases the touch target size for all users. It also reduces the number of redundant focus targets, which benefits people using screen readers and keyboard/switch control.

Help users understand the purpose of each link when viewed on a mobile device.

Help users understand the purpose of each link from the link text alone when viewed on a mobile device.

Labels and instructions

Ensure that labels or instructions are provided to mobile users and mobile screen reader users when content requires user input.

Operating touch screens

Provide users with the ability to operate touchscreens with one finger and reduced gestures.

WCAG Mobile Related Guidelines

WCAG 2.0 Guidelines Related to Mobile Accessibility

Set your website to respect prefers-reduced-motion and prevent animation from being displayed.


When the user selects an anchor/jump link the page will smooth-scroll to the content selected, instead of a hard and abrupt jump.

Users can set their OS to indicate their motion preference.

This is supported by Chrome, Safari, Firefox, Edge

The 'prefers-reduced-motion' CSS Media Query will respect that choice.

Please see additional information.

Screen reader users frequently navigate web pages, using the TAB key, through actionable items such as links, buttons and form controls.

Assistive technology can provide users with a list of links on a webpage and they can navigate from this list.

In these cases the links are taken out of context from the surrounding text but should still provide the user with enough information.

The button/link text alone should convey the function and purpose of the link.


Best Practice

Best practice is to provide descriptive link text or button labels by default. However, in situations when this is not possible the following techniques can be used.

Color Contrast Checker by WebAIM

Color Blindness Filter by Toptal

Accessible PDFs - Adobe Acrobat Pro and Microsoft Word

How to make your Microsoft Word document accessible by Microsoft:

How to create and verify accessible PDFs by Adobe:

How to create accessible forms inside Adobe:

How to create and repair tables inside Adobe:

How to use the accessibility checker by Adobe:

How to repair or remediate old PDFs by Adobe:

Web Accessibility Testing Tools

Writing Effective ALT Text for Images