1 of 38

Completing an Accessibility Audit

San Francisco Digital Services

2 of 38

What We Will Review

Different types of tests that you need to perform.
How to approach testing.
Documenting accessibility issues.
Deep dive and demo of a few accessibility guidelines.
How to test and comply with these guidelines.

3 of 38

Test and Complete an Accessibility Audit

The only way to know if your website is compliant with the city's Digital Accessibility and Inclusion Standards is to test it and complete an accessibility audit.

4 of 38

Types of Accessibility Tests

5 of 38

Types of Accessibility Tests

Automated Testing
Manual Testing
Screen reader testing
Keyboard only testing
Mobile testing

6 of 38

Automated Testing

An automated test will scan and evaluate your website for potential accessibility issues.
Will scan the code against the WCAG 2.1 guidelines which are the foundation for the DAIS.
May report false positives.
Review the automated test report and identity if they are valid issues.
An automated test will only identify 30-40% of issues.
Example of automated test report .

Automated Testing

Let's talk a little bit more about automated testing.

Again, the automated test involves using a software tool that will automatically scan and evaluate your website for potential accessibility issues.

The tool will scan the code against the WCAG 2.1 guidelines which are the foundation for the City's Digital Accessibility and Inclusion Standards.

The automated testing tool is a good starting point and very helpful for websites with lots of content.

Depending on the size of your site and the tool used it could take anywhere from 30 minutes to several hours to complete an automated scan.

Once the scan has finished it will generate a report with any accessibility issues that it identified.

Basically, the automated testing tool will flag any "potential" issues and may report false positives.

So you will then have to review the automated test report and identity if they are valid accessibility issues.

I use an automated testing tool called axeMonitor.

I will show you an example of what this automated report looks like.

And different tools will produce different types of reports. https://ccsanfrancisco-axemonitor.dequecloud.com/worldspace/organizationProject/summary/36?share=0e8a91d2dc451de26db5fcf7c7e70d8eaa7cc4b8

This report will group the issues into different categories and reference the accessibility standard that it scanned against.

It will also list the priority or severity of the issue, a brief description of the issue, the number of instances with this issue as well as the number of pages related to a specific issue.

However, it's important to keep in mind that an automated test will only be able to identify about 30-40% of accessibility issues.

So that's why it's important to combine your automated test with manual testing.

7 of 38

Document Issues

Capture any issues in a separate document.
Add links to pages or documents that don’t comply with a specific accessibility guideline.
Example of audit report document.

Document Issues

After I have reviewed the automated report and identified what are valid issues. I will then capture those issues in a separate Audit Report Document.

I will show you an example of an audit report template that I use. https://docs.google.com/document/d/1vMUcCmYc5ChKTZhfWM9JTk7UVUgrd2U4Criam5mphHg/edit

So this template captures the types of tests performed, the type of content that was tested, as well as a list of the accessibility guidelines I should be testing for.

And here you would just add links to pages or documents that don’t comply with a specific accessibility guideline.

Please feel free to copy this template and use for your own audit.

This template is also available through the DAIS SharePoint site. https://sfgov1.sharepoint.com/sites/DigitalAccessibilityInclusionStandard?cid=dd713e39-0981-40a1-9dc4-b9fbdbb7a929

8 of 38

Manual Testing

First test any global elements such as site header, footer, repetitive navigation menus.
Document global issues in the audit report document.
Complete manual testing of content area. Content between the header and footer.
Document issues.

9 of 38

Manual Screen Reader Testing

A screen reader will read out loud the web page content to the user.
A screen reader interacts with the web page by using different keyboard keystrokes.
JAWS is the most popular screen reader. Windows based and requires a paid license.
NVDA is a free, open source screen reader.
Guide on testing with screen readers.

Manual Screen Reader Testing

I will start out with performing manual testing using a screen reader.

A screen reader will read out loud the web page content to the screen reader user.

The screen reader user will then interact with the web page by using different keyboard keystrokes.

I use the JAWS screen reader which is the most commonly used screen reader.

It is Windows based and requires you to obtain a paid license. I believe it's around $1200 per license.

There are also free, open source screen readers out there, such as NVDA.

You can find more information about different types of screen readers and how to test with screen readers in our Accessibility Guide which is also available through the DAIS Sharepoint site.

https://sfgovdt.jira.com/wiki/spaces/SFGOV/pages/1917157493/Testing+with+Screen+Readers+on+Desktop.

10 of 38

Manual Keyboard Only Testing

Users who rely on only using a keyboard to access online content.
Keyboard only users are not able to use a mouse.
Keyboard only users will use different keystrokes to navigate a web page and activate interactive elements.
Will use the TAB key to navigate through links, buttons and form controls.
Keyboard only testing guide, including common keystrokes for different web interactions.

Manual Keyboard Only Testing

The next manual test that I will perform is a keyboard only test.

This is for users who rely on only using a keyboard to access online content.

They are not able to use a mouse.

Keyboard only users will use different keystrokes to navigate a web page and interact with site content.

For example they will use the TAB key to navigate through actionable items such as links, buttons and form controls.

And then use other keystrokes to activate those elements once they receive keyboard focus.

I have created a guide related to keyboard only testing including common keystrokes for different web interactions.

This is what it looks like.

https://sfgovdt.jira.com/wiki/spaces/SFGOV/pages/1917157453/Testing+for+Keyboard+Accessibility

And you can also find this guide through the DAIS Sharepoint site.

Again I will start out by testing any global elements such as the site header, footer, repetitive navigation menus.

Then I'll capture any issues that I have identified in the audit report document.

I will then move on to manual keyboard only testing within the content area.

11 of 38

Manual Mobile Testing

Website content must be fully accessible on mobile devices, including the use of mobile screen readers.
iOS and Android mobile devices both have built in screen readers. VoiceOver and TalkBack.
Mobile screen reader users use different tapping and swiping gestures to navigate through a web page and interact with site content.
Mobile screen reader testing guide and mobile best practices.

Manual Mobile Testing

The next manual test that I will perform is a mobile test using an actual mobile device.

Your website content must also be fully accessible on mobile devices, including the use of mobile screen readers.

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

Mobile screen reader users use different tapping and swiping gestures to navigate through a web page and interact with site content.

I have also created a guide on how to test with mobile screen readers including mobile accessibility best practices.

This is what the guide looks like and it’s available through the DAIS Sharepoint site.

https://sfgovdt.jira.com/wiki/spaces/SFGOV/pages/3279585306/Mobile+Accessibility

I will again start out by testing any global elements such as the site header, footer, repetitive navigation menus.

Then I'll capture any issues that I have identified in the audit report document.

I will then move on to manual mobile testing within the content area.

12 of 38

Time Required for Testing

Will vary depending on the number of pages on the site, how much functionality and interactive elements there are on the site
Forms are time consuming to test.
Static content is faster to test than interactive content.
PDF documents can be time consuming to test.
Some automated testing tools will test PDF documents.
Testing guides/resources on the DAIS Sharepoint site.

13 of 38

Demo of Accessibility Guidelines

14 of 38

Provide Alternative Description (ALT Text) for Images

15 of 38

Overview

Provide alternative text for images for screen reader users.
ALT text helps screen reader users understand the meaning of an image.
The screen reader will read out loud the ALT description to the user.

16 of 38

Guideline Expectations

As a screen reader user I should be provided with meaningful alt text for non-decorative images.
As a screen reader user I should be able to bypass decorative images that have no meaning.

17 of 38

Non-Decorative Images

A non-decorative image is a graphic that has meaning.
It could include important text that needs to be conveyed to a screen reader user who is unable to see the image.
For example the department name in a logo.

The text and icon is one image.

18 of 38

Decorative Images

Decorative images have no real meaning.
They don’t include important text and may just be there to provide visual decoration for sighted users.
Often times decorative images will display a link next to the image that describes what the image is trying to convey. It would be redundant to have an ALT text that conveys the same thing as the link.
A screen reader will bypass images that have been marked as decorative images.

19 of 38

How to Comply - Non-Decorative Images

Meaningful and compliant ALT text:

Non-meaningful and non-compliant ALT text:

How to Comply - Non-Decorative Images

Next I'm going to briefly talk about how to comply with the ALT Text guideline and also demo how a screen reader will read out the ALT text.

So the first example here shows you what a meaningful ALT text should look like in the actual code for the Human Services Agency logo.

It correctly includes the text that appears in the image and successfully meets the ALT text guideline.

And the second example shows you a non-compliant, non-descriptive ALT text for the Human Services Agency logo since it doesn't communicate the text that appears within the logo. So this would be an issue as it doesn’t comply with the ALT text guideline to provide meaningful ALT text.

Okay. So now I'm going to demo how the screen reader will read out the ALT text for the logo on the SFHSA.org site.

So I'm going to use a virtual screen reader through a tool called AssistivLabs.

https://assistivlabs.com/dashboard

First I'm going to select the screen reader that I want to use.

So I want to use the JAWS screen reader.

Then I'm going to hit "Start Testing" and then enter the URL to the website that I want to test.

Once I've done that I will select the JAWS screen reader icon at the bottom of the screen.

And now I’m going to use the TAB key to navigate to the logo.

Once the logo receives keyboard focus the screen reader will announce the image as "San Francisco Human Services Agency Link Graphic" .

In this case the department logo is both a link and a graphic.

20 of 38

How to Comply - Decorative Images

Compliant ALT text:

Non-compliant ALT text:

21 of 38

Automated Testing of ALT Text Guideline

The automated testing tool will scan all images across the site and identify if an ALT text is present.
If there is no ALT text present it will flag the image as a failure for not meeting the accessibility guidelines.
The automated test will not be able identify if the alt text is meaningful or if it's a decorative image.

22 of 38

Review Automated Test of ALT Text Guideline

Review the automated report and identify if it flagged images without alt text. Example of automated report.

If there is no ALT text present you need to identify:

If it's an image that has meaning (logo with dept name)

If it's an image that has meaning and no alt text is present, it's an issue. Image needs to be updated with meaningful alt text.

b) If it's a decorative image that has no meaning.

If the image has not been marked as a decorative image in the code it's an issue. Needs to be marked as decorative.

Review Automated Test of ALT Text Guideline

So the next step would be to review the automated report to see if it flagged any images without alt text.

Here is an example of what that report might look like.

https://ccsanfrancisco-axemonitor.dequecloud.com/worldspace/organizationProject/summary/11?share=13a5f17d8a8cd8fd467ce79dfce7a6d6dc864d03

So if we look at the very bottom of this automated report it has flagged 640 potential instances where ALT text has not been provided. This might just be a case where the same image is repeated on every single page, for example in the header or footer.

So if there is no ALT text present you need to identify:

a) If it's an image that has meaning, for example a logo with a department name.

If it's an image that has meaning and no alt text is present, then it's an issue.
And the image reference needs to be updated with a meaningful alt text.

b) If it's a decorative image that has no meaning and the image has not been marked as a decorative image it's an issue.

And the image reference needs to be updated and marked as a decorative image.

23 of 38

Manual Testing of ALT Text Guideline

Review images that already have ALT text present to identify:

If the ALT text is meaningful.

If the ALT text is not meaningful it’s an issue.
ALT text needs to be updated with meaningful ALT text.

b) If it's a decorative image that has no meaning.

If ALT text has been provided it’s an issue.
Image needs to be updated and marked as decorative.

Review existing ALT text using this tool.

Manual Testing of ALT Text Guideline

The next step would be to complete a manual test of images that already have ALT text present and identify:

a) If the alt text is meaningful.

If the ALT text is not meaningful it's an issue.
And the ALT text needs to be updated with a meaningful alternative description

b) If the image is decorative and has no meaning and alt text has been provided it's an issue.

And the image needs to be updated and marked as a decorative image.

To view ALT text that is already present in images you can use this helpful online scanning tool that will visually show you in the browser the actual ALT text that exists in the code.

It's called Waive by WebAIM and it's a free tool.

https://wave.webaim.org/

ENTER sfhsa.org

Here you would just need to enter the URL of the page you want to review and then submit it.

For example, if you look at the white text with a green background next to the department logo that says San Francisco Human Services Agency.

That's the actual ALT text for the logo.

So this ALT text is meaningful as it includes the text within the logo.

So the ALT text for this image successfully meets this guideline.

24 of 38

Skip Repetitive Navigation

25 of 38

Overview

Allow screen reader and keyboard only users to skip repetitive navigation, such as global navigation menus in the header, that appear on every single web page.
As a screen reader and keyboard only user I should be able to bypass repetitive navigation and skip directly to the main content area of the page.

.

26 of 38

Guideline Expectations

A “skip to main content” link needs to be incorporated to all site pages.
The link needs to be visible to sighted keyboard only users.
The link should be placed at the very top of the page and redirect users to the beginning of the main content area.

27 of 38

Type of Test

This is a manual test using only the keyboard or a screen reader.
An automated test is not able to evaluate if this guideline has been met.
Example: Lighthouse for the Blind

28 of 38

How to Test

When web page has loaded press the TAB key a few times.
The “Skip to main content” or “Skip to content” link is the first link that should appear at the top of every web page.
The "Skip to main content" link is by default hidden and only becomes visible to a sighted user when pressing the TAB key.
When the “Skip to main content” link receives keyboard focus, press the Enter key to activate the link. You should be redirected to the main content area of the page.

If keyboard only test is successful, screen reader users will also be able to access “skip to main content” link.

How to Test

You should be able to access the “Skip to main content” link by pressing the TAB key on your keyboard a few times.
Once I press the TAB key the “Skip to main content” or “Skip to content” link is the first link that should appear at the top of every web page.
The "Skip to main content" link is by default hidden and only becomes accessible and visible to a sighted user when pressing the TAB key on the keyboard
When the “Skip to main content” link receives keyboard focus, you would press the Enter key on your keyboard to activate the link. And you should now be redirected to the main content area of the page.

If this keyboard only test is successful it means that the screen reader will also announce the “Skip to main content” link to screen reader users.

So on the Lighthouse for the Blind website they are fully compliant with this guideline.

29 of 38

How to Comply

<a href="#maincontent Class="skip-link visually-hidden visually-hidden-focusable">Skip to main content</A>

<h1>Heading</h1>

<p>This is the first paragraph</p>

</main>

30 of 38

Provide Keyboard Focus Indicator

31 of 38

Overview

This guideline is for sighted users who rely on only using a keyboard to access online content.
They are not able to use a mouse.
Sighted keyboard only users typically use the TAB key to navigate through interactive elements on a web page, such as links, buttons, fields for inputting text, etc.
When an item has keyboard "focus", it can be activated or manipulated with the keyboard.

.

32 of 38

Guideline Expectations

As a sighted keyboard only user I should be provided with a keyboard focus indicator for links, buttons, and form elements.
The keyboard focus indicator should be a visual border or outline that appears around the item that has keyboard focus.

.

33 of 38

Type of Test

This is a manual test using only the keyboard.
An automated test is not able to evaluate if this guideline has been met.
Example: Human Services Agency website.

34 of 38

How to Test

Once the web page has loaded in the browser press the TAB key to start navigating through the page.
When a link, button or form control receives keyboard focus a noticeable border should be displayed around the actionable item to let sighted keyboard only users know where they are on the page.
The user will then use different keystrokes to activate actionable items.

35 of 38

How to Comply

A sighted keyboard only user must be provided with a visual indicator of the element that currently has keyboard focus.
The keyboard focus indicator should have enough color contrast between the foreground and background

36 of 38

Example on How to Comply in the Code

HTML Code:

<button>Example button</button>

css Code:

button {

background-color: #236AB8; /* medium-dark blue */

color: white;

}

main button:focus {

outline: 3px #fff5be solid; /* yellow */

outline-offset: -4px;

}

37 of 38

Guides and Resources

38 of 38

Guides on How to Test and Comply

You can find links to tools and guides on how to test for these guidelines through the DAIS Sharepoint site.
You can find information on how to comply with all of these guidelines in our Accessibility Guide and Checklist.