1 of 72

Introduction to

Digital Accessibility

San Francisco Digital Services

2 of 72

Table of Contents

What is Digital Accessibility?
Why is Accessibility Important?
Accessibility Standards and Guidelines
What Types of Users Do You Need to Design For?
Designing for Digital Accessibility
Writing for Digital Accessibility
Developing for Digital Accessibility
Testing for Digital Accessibility
Accessibility Resources and Guides

3 of 72

What is digital accessibility?

4 of 72

What is Digital Accessibility?

Accessibility means removing barriers.

When digital products are correctly designed, developed, and edited, all users have equal access to information and functionality.

5 of 72

Why is accessibility important?

6 of 72

Why is Accessibility Important?

In the United States, there are over 56 million people with a disability.

Approximately 20% of the US population requires some form of assistive technology to browse online content. That could be:

Screen reading software
Screen magnifiers
High contrast views
Keyboard only navigation
Voice over on mobile devices
Speech to input devices
Braille (allows users to read by touch)

7 of 72

Accessibility Standards and Guidelines

8 of 72

Web Content Accessibility Guidelines (WCAG)

Worldwide accessibility guidelines
3 compliance levels: Level A, Level AA and Level AAA
2.1 version of the WCAG standards were released in 2018
WCAG 2.2 version was released in 2023.

9 of 72

Section 508 Standards

US federal accessibility standards
Section 508 was last updated in 2017
Aligns with the WCAG 2.0 Level AA guidelines

10 of 72

City Digital Accessibility and Inclusion Standards

City accessibility standards
Often referred to as “DAIS”
Map to the WCAG 2.1 Level AA accessibility guidelines
Also covers some city specific standards

11 of 72

Accessibility Standards and Guidelines

Last year the Department of Justice updated the Americans with Disabilities Act
Requires all state and local governments with a population of more than 50,000 to comply with the WCAG 2.1 Level AA guidelines by April 2026

12 of 72

What types of users do you need to design for?

13 of 72

Accessibility User Groups

When designing your digital content it’s important to take the following user groups and disabilities into account.

Visual	Screen reader users, keyboard users, vision impairment, blindness, color blindness, speech to input users
Physical	Keyboard only users, mobility impairment, speech to input users
Auditory	Hearing impairment, deafness
Cognitive	Learning disability, reading disorder, language barriers/English as a second language

14 of 72

Considerations for Creating Accessible Content

What are some of the key considerations in order to make your digital content more accessible to people with disabilities?

Design for Accessibility
Write for Accessibility
Develop for Accessibility
Test for Accessibility

15 of 72

Designing for Digital Accessibility

16 of 72

Avoid PDF Documents and Attachments

Avoid the use of PDF documents and attachments when creating digital content.

PDFs and attachments are difficult for screen reader and keyboard only users to navigate.
The city’s Digital Accessibility and Inclusion Standards state that “PDFs should be eliminated in favor of web pages because they do not work well on mobile devices”.
Unlike web pages, PDF documents are not responsive and do not adjust to your screen size.
Users with learning disabilities can easily become disoriented when viewing PDF documents and attachments, because there is no website navigation available.

17 of 72

Create Accessible PDFs and Attachments

Best practice is to provide digital content in online web page format that is fully accessible to all users.
If for some reason you have to create content in PDF or Word format, you must properly format and tag your PDF and Word documents in order to make them fully accessible to screen reader and keyboard only users.
Here is a step by step guide on how to create accessible PDF and Word documents.

18 of 72

Color and Color Contrast - Body Text

Ensure that there is sufficient color contrast between text and background.

19 of 72

Color and Color Contrast - Link Text

Ensure that link text has sufficient color contrast with the background color as well as in relation to the body text.

20 of 72

Don’t Rely on Color Alone to Convey Information

Color should not be the only way information is conveyed.
When using color to differentiate elements, also provide additional identification that does not rely on color perception.

21 of 72

Don’t Rely on Color Alone to Convey Info - Part 2

For example, use an asterisk in addition to color to indicate required form fields.

22 of 72

Don’t Rely on Color Alone to Convey Info - Part 3

Use labels to distinguish areas on graphs.

23 of 72

Ensure Interactive Elements are Easy to Identify

Some people can't use a mouse and use only a keyboard to navigate through web pages.
Those users frequently use the TAB key on the keyboard to navigate through actionable items such as links, buttons and form controls.
It is important that those users can reach all interactive elements using only the keyboard

24 of 72

Ensure Interactive Elements are Easy to Identify

It needs to be clear to sighted keyboard only users which element has keyboard focus.
Provide a visible keyboard focus indicator such as a border or outline that appears when actionable items such as links and buttons receive keyboard focus.
The keyboard focus indicator must provide sufficient color contrast between foreground and background.

25 of 72

Provide Clear and Consistent Navigation

Ensure that navigation across pages has consistent naming, styling, and positioning.
Help users understand where they are by providing orientation cues, such as clear headings and navigation labels.

26 of 72

Provide Accessible Audio and Video Content

Any audio and video related content must be fully accessible to vision and hearing impaired users.

27 of 72

Provide Synchronized Captions

Provide hearing impaired users with synchronized captions for any pre-recorded videos with audio.

28 of 72

Provide a Text Transcript - Part One

Provide a text based transcript of audio only content for hearing impaired users.

Provide a text based transcript of video only content for vision impaired users.

29 of 72

Provide a Text Transcript - Part Two

Transcripts are a WCAG 2.1 Level AAA requirement when it comes to pre-recorded videos with audio.
It is best practice to always provide a separate transcript for video related content.
Transcripts are needed for people who are Deaf-blind and use braille.
Braille users read content by touch.
Individuals whose vision is too poor to reliably read captions and whose hearing is too poor to reliably hear dialogue can access the transcript through braille.

30 of 72

Slideshows and Moving Content - Part 1

Avoid the use of slideshows and moving content as it is not fully accessible to keyboard only users and screen reader users.

31 of 72

Slideshows and Moving Content - Part 2

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

32 of 72

Create Designs That Are Responsive

Ensure that content, text size, line height, text spacing and navigation adapt to different screen sizes.

33 of 72

Create Accessible Data Tables - Part 1

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.
Proper markup/tagging must be used to make a programmatic association between elements within the table.
When the proper HTML markup or tagging (PDF/Word docs) 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.

34 of 72

Create Accessible Data Tables - Part 2

Provide column and/or row headers.
Provide a table caption that describes the content in the table.
Avoid using tables for layout purposes.

35 of 72

Writing for Digital Accessibility

36 of 72

Provide Alternative Description for Images

Provide alternative descriptions for images.
This helps users who rely on assistive technology such as a screen reader to understand the meaning of the image.
Screen readers will announce the ALT description to the user.

37 of 72

Provide Meaningful ALT Text for Images

Provide meaningful alternative descriptions for images.
For example a department logo where the department name is part of the image.

Meaningful ALT Text:

Non-meaningful ALT Text:

38 of 72

Use Headings to Convey Meaning and Structure

Use main headings and subheadings to organize content.
Use short headings that clearly describe each section.
Good headings should provide an outline of the content.

39 of 72

Create a Logical Reading Order

Create a logical reading order for vision impaired users who rely on using assistive technology such as a screen reader to access online content.
Screen reader and other assistive technology users frequently navigate content by heading structure.
These users can pull up a list of all the headings on a page to get a quick overview of the type of content that is available.
This means that headings need to be properly tagged and nested in the markup or in your PDF document.

40 of 72

Proper Nesting of Headings

<h1>Page Title</h1>

<h2>Heading Two</h2>

<h3>Heading Three</h3>

<h4>Heading Four</h4>

<h2>Heading Two</h2>

<h3>Heading Three</h3>

<h4>Heading Four</h4>

Heading 1

Heading 2

Heading 3

Heading 4

Heading 2

Heading 3

Heading 4

41 of 72

Provide Descriptive Link Text - Part 1

Screen reader users frequently navigate content, using the TAB key on the keyboard, through actionable items such as links, buttons and form controls.
Assistive technology can provide users with a list of links 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.

42 of 72

Provide Descriptive Link Text - Part 2

Write link text so that it describes the content of the link target.
Don’t display the absolute URL as the link text. For example:

https://docs.google.com/presentation/d/1u5Ga3RclMODBUmbl_ecI8MchB_XMN5IrdjS2srt4oEs/edit#slide=id.g33bb47331c4_0_100

Avoid using ambiguous link text, such as ‘click here’ , ‘read more’, ‘view all’, etc.

43 of 72

Provide Help Text and Feedback

Help screen reader users avoid and correct mistakes by providing help text on how to interact with elements such as forms.
Provide feedback for interactions, such as confirming form submissions, alerting the user when something goes wrong, or notifying the user of changes on the page.
People who are blind or have low vision need non-visual instructions.
Don’t rely on color alone to convey the error or alert message when something is not completed correctly or information is missing.

44 of 72

Provide Inline Error Messaging

For example, provide inline error messaging in connection with forms.

This allows screen reader users to correct errors immediately while they are completing the form.

45 of 72

Provide Descriptive iFrame Titles

Third party content (such as videos, interactive maps, Power BI dashboards, etc) that are embedded using an iFrame, must include an iFrame title that describes the content within the iFrame.
Help screen reader users understand what type of content is in the iFrame.
The iFrame title is announced by screen readers.
Provide concise and meaningful iFrame titles.
Example: <iframe src="unemployment.htm" title="Interactive data showing unemployment rate in San Francisco">

46 of 72

Keep Content Clear and Concise

Use simple language that is easy for users with any sort of learning disability to understand.
Write content at a 5th grade reading level.
Write in short, clear sentences and paragraphs.
Avoid using unnecessarily complex words and phrases.
Expand acronyms on first use. For example, Department of Public Health (DPH).
Consider providing a glossary for terms readers may not be familiar with.

47 of 72

Language Access

Provide human translation of vital information in the languages defined by the city’s Language Access Ordinance.

English
Spanish
Chinese
Filipino
Vietnamese - NEW

48 of 72

Developing for Digital Accessibility

49 of 72

Create Programmatically Accessible Content

One of the most important aspects to ensure that your content is fully accessible to screen reader users and keyboard only users has to do with creating accessible markup and code.
Ensure that all content, interactive elements and functionality is programmatically accessible to screen reader users as well as keyboard only users.
Content needs to be properly marked up on the backend. Using proper HTML code.
Write semantic markup that is easily accessible to users who rely on assistive technology such as a screen reader.

50 of 72

Explicitly Associate Form Instructions and Labels with Their Respective Form Control

For example screen reader users often navigate forms by using the TAB key on the keyboard, to jump from form control to form control..
This means that form labels and help text need to be programmatically and explicitly associated with their respective form control.
When the form control receives keyboard focus the screen reader will announce the form label and help text.
If a form input is required we also need to include that information in our markup so that screen readers will make that announcement.

51 of 72

Explicitly Associate Form Instructions and Labels with Their Respective Form Control

You must be the business owner or the authorized representative of a nonprofit.

</div>

52 of 72

Ability to Skip Repetitive Navigation

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

53 of 72

Incorporate Landmarks and Landmark Roles

Break the web page into regions and assign landmarks and landmark roles.
Assistive technologies such as screen readers provide shortcut keys to navigate through page elements that have been defined as landmarks and landmark roles.
Screen reader users can pull up a list of all landmarks on a page and then navigate to them using the shortcut keys.

<p>Put company logo, etc. here.</p>

<ul>

<li>Put primary/global navigation here</li>

</ul>

</nav>

</header>

<p>Put main content here.</p>

</main>

<p>Put copyright, and footer related content here.</p>

</footer>

54 of 72

Specify The Default Human Language

Ensure that the default human language of each web page can be programmatically determined.
This is to help screen readers load the correct pronunciation rules.
Make sure that a “lang” attribute has been specified in the markup on every web page.

Example:

55 of 72

Tagging and Nesting of Headings

<h1>Page Title</h1>

<h2>Heading Two</h2>

<h3>Heading Three</h3>

<h4>Heading Four</h4>

<h2>Heading Two</h2>

<h3>Heading Three</h3>

<h4>Heading Four</h4>

Headings need to be properly tagged and nested in the markup in order to create a logical reading order for screen reader users.

56 of 72

Testing for Digital Accessibility

57 of 72

Types of Accessibility Tests

Automated Testing

An automated test will scan the markup of your website for potential accessibility issues.
Basic/standard automated testing tools will identify 25-30% of all accessibility issues.

Manual Testing

using a screen reader
using only a keyboard
using a mobile device in combination with a mobile screen reader
a visual review of content and design

58 of 72

axeMonitor - Automated Testing

axeMonitor is an automated testing tool by Deque.

Will scan all your web pages against a set of accessibility rules.
It scans the code on the backend.
Will scan PDF documents.
Will provide an accessibility report.
We do have a license for this tool.

IMPORTANT:

Automated scanning tools such as axeMonitor is only able to identify 25 to 30% of all accessibility issues.

59 of 72

Increase Your Accessibility Validation Coverage

Increase your accessibility validation coverage to ensure that you are DAIS compliant.
Combine automated testing with manual testing.
Use an end-to-end testing framework and write automated, custom accessibility tests.

60 of 72

New Automated Accessibility Testing Platform

Last year I was working with Joni to set up an automated accessibility testing platform using Playwright.
HUGE THANKS TO JONI for making this a reality and for setting up the entire Playwright testing framework and the foundation for this platform.
This is a tool for engineers to use to validate accessibility compliance when checking in new and updated code.

61 of 72

Playwright Accessibility Testing Platform Goals

The goals with this platform are to:

increase our automated accessibility validation coverage
reduce manual testing by writing custom Playwright tests
identify potential accessibility issues early in the development cycle when new code is checked in

62 of 72

Playwright Accessibility Testing Toolkit

Accessibility testing platform is integrated with our new sf.gov Wagtail templates.
I have been writing custom accessibility related Playwright tests to increase our accessibility validation coverage for sf.gov and I'm continuing to write additional tests.
Here is the link to the Playwright Accessibility Testing Toolkit that I have created.
The toolkit includes a list of all accessibility related Playwright tests that have been created to date and what each test validates.
Have created around 90 custom tests to date.

63 of 72

Integrate Playwright Testing to other Platforms

It would be great if we would also integrate the Playwright accessibility testing framework to:

the forms platform
the housing app

64 of 72

Keyboard Testing

Test your content to validate that it can be accessed by keyboard only users.
These are users who rely on only using a keyboard to access online content.
These users are unable to use a mouse.
This is a manual test.
Here is a keyboard testing guide on what keystrokes you need to test for for different types of interactions.

65 of 72

Screen Reader Testing

Manual testing using a screen reader.
The most commonly used screen reader is JAWS by Freedom Scientific.
There is a free, open source screen reader called NVDA.
Both JAWS and NVDA are windows based tools.
You could also use voice over on the MAC.
We also have another tool called AssistivLabs that allows you to virtually test content with screen readers in combination with different browsers

66 of 72

Mobile Testing with Mobile Screen Reader

Another manual test that you would want to perform is with an actual mobile device using a mobile screen reader.
The mobile screen reader is already built in to your mobile device.
Mobile screen reader users use different swiping and tapping gestures to navigate and access online content.
Here is a step by step guide with instructions on how to conduct mobile screen reader testing using different swiping and tapping gestures.

67 of 72

Color Contrast Checker

WebAIM provides a free color contrast checker that validates compliance with WCAG Level AA standards.

68 of 72

Adobe Acrobat Pro - Testing PDF Documents

Adobe Acrobat Pro allows you to test PDF documents for accessibility compliance.

Comes with a built in accessibility checker.
Here is a step by step guide on how to test PDF documents for accessibility compliance.

69 of 72

Hemingway App

Hemingway is an online tool that will test the reading level of your content.

You can enter your website content and Hemingway will tell you the current reading level and provide suggestions on how to update your content in order to make it easier for users to understand.
Providing content at a 5th grade reading level is recommended.

70 of 72

Wave by WebAIM

Wave is a free, online accessibility evaluation tool.

Will scan one webpage at a time.
It scans the code on the backend.
Will visually show you where on the webpage an accessibility issue might appear.

71 of 72

Accessibility Resources and Guides

72 of 72

Accessibility Resources and Guides

And lastly I also wanted to share links to various accessibility resources and guides that are available.

I have created an accessibility checklist and guide that you can refer to in terms of how to comply with DAIS from a design, content and development perspective.

The guide also includes:

step by step guides on how to create accessible forms and PDF documents
And as mentioned earlier, guides on how to conduct keyboard only testing as well as mobile screen reader testing

I have also included a link to an accessibility audit template that I have created that maps to each of the respective WCAG 2.1 Level AA guidelines.

And there is also a link here to the accessibility sharepoint site.

And please feel free to reach out to me anytime if you have questions on how to remediate accessibility issues, if you would like me to review and test new content and functionality for accessibility compliance or if you just want guidance and general feedback on accessibility best practices and how to comply with DAIS.

And then I also just wanted to mention that Amy is going to provide accessibility training to sf.gov content editors and also provide accessibility training on how to create accessible PDF documents. So that will be super helpful.

And I will also share a link to this presentation in Slack.

And thanks so much for attending this presentation.