Author: gladden.9@osu.edu

Comparing automated accessibility checkers and the issues that they can find

by

Testing the accessibility of webpages can be challenging. Only a certain percentage of issues can be found with automated tools like WAVE, ANDI, or Axe. It would be convenient if testing tools could find all issues, but in practice some automated checkers are better than others at finding different types of issues. If you want to do a thorough accessibility evaluation, you will likely need to test with several different tools to find the most issues.

Here’s a comparison of issues that various automated accessibility checkers can find:

Issue

WAVE

Accessibility Insights

Lighthouse

ANDI

Axe

Language missing

Yes

Yes

Yes

Yes

Yes

Iframe missing title attribute

No

Yes

Yes

Yes, under focusable elements

Yes

Missing alternative text

Yes

Yes

Yes

Yes, under Graphics/Images

Yes

Long alternative text

Yes

No

No

No

No

Aria attribute not allowed

No

Yes

Yes

No

No

Underlined text (Pseudo links)

Yes

No

No

No

No

Skipped heading level

Yes

No

Yes, says Heading elements are not in a sequentially-descending order

No, under Structures > Headings

No

Poor text contrast

Sometimes

Yes

Yes, says background and foreground colors do not have a sufficient contrast ratio.

Yes

Yes

Missing table headers

Yes, will call it a ‘layout table’

No

No

Yes, under tables

No

Touch targets without sufficient size or spacing

No

No

Yes

No

No

‘Yes’ for the tool can find and ‘No’ for the checker can’t find. ‘Sometimes’ means that the checker sometimes can find the issues but not in all cases. For example, WAVE can check contrast ratios of live text but not in images of text, such as in a logo.

If your organization is using PopeTech as its compliance scanner, the WAVE browser extension is a good tester to start with because PopeTech uses WAVE as it’s accessibility engine. In the table above I’ve compared WAVE to other popular automated testers. ANDI is a nice, lightweight bookmarklet that can find a lot of accessibility issues.

Accessibility Insights offers not only automated testing with the Quicktest, but also can guide you through the steps of a conformance testing methodology. So, if you need to do more through manual testing, Accessibility Insights can guide you through that step by step. The only downside is that it doesn’t always refer to WCAG success criteria (SC) as you go through the steps. It can be a good reference to know what WCAG SC each step is related to.

Chinese languages test page for Screen readers

by

This is a languages test page. The following paragraphs are marked up for Chinese (lang=”zh”). These can be used for testing the accent of a screen reader. The two letter language code in the lang attribute should match the language the text was written in.

The paragraph in English (lang=”en”)

If a language isn’t specified, the screen reader will read the page in the user’s default language. That may result in a bad accent that’s difficult to understand. To specify a language for the page, add the ‘lang’ attribute to the HTML tag. For example: html lang=en.

Paragraph in the Chinese language (lang=”zh”), simplifed (zh-Hans):

如果未指定语言，屏幕阅读器将使用用户的默认语言阅读页面。这可能会导致口音难懂。要为页面指定语言，请将“lang”属性添加到 HTML 标记。例如：html lang=zh.

Paragraph in the Chinese language (lang=”zh”), traditional (zh-Hant):

如果未指定語言，螢幕閱讀器將以使用者預設的語言閱讀頁面。這可能會導致口音不好，難以理解。若要指定頁面的語言，請將「lang」屬性新增至 HTML 標記。例如: html lang=zh.

The key to getting NVDA to speak non-Latin languages is to switch to voice synthesizer like eSpeak NG that is more multilingual. It can be done under Preferences > Settings > Voice > synthesizer. The default MS OneCore voices sound good for American English but don’t support a lot of other languages. The Hong Kong Blind Union has an addon for NVDA that can allow it to better speak Chinese.

Resources

ISO 2 Letter Language Codes reference

Google Translate

ISO 639.2 Codes for the Representation of Names of Languages

Devanagari script languages test page for Screen readers

by

This is a languages test page. The following paragraphs are marked up for three languages that use Devanagari script. These can be used for testing the accent of a screen reader. The two letter language code in the lang attribute should match the language the text was written in. Nepali, Hindi, and Garhwali are languages that use the Devanagari script (a non-Latin alphabet).

The paragraph in English (lang=”en”)

If a language isn’t specified, the screen reader will read the page in the user’s default language. That may result in a bad accent that’s difficult to understand. To specify a language for the page, add the ‘lang’ attribute to the HTML tag. For example: html lang=en.

Paragraph in the Hindi language (lang=”hi”):

यदि कोई भाषा निर्दिष्ट नहीं है, तो स्क्रीन रीडर पृष्ठ को उपयोगकर्ता की डिफ़ॉल्ट भाषा में पढ़ेगा। इसका परिणाम खराब लहजे में हो सकता है जिसे समझना मुश्किल है। पृष्ठ के लिए एक भाषा निर्दिष्ट करने के लिए, HTML टैग में ‘लैंग’ विशेषता जोड़ें। उदाहरण के लिए: html lang=hi.

Paragraph in the Nepali language (lang=”ne”):

यदि कुनै भाषा निर्दिष्ट गरिएको छैन भने, स्क्रिन रिडरले प्रयोगकर्ताको पूर्वनिर्धारित भाषामा पृष्ठ पढ्नेछ। यसले नराम्रो उच्चारण गर्न सक्छ जुन बुझ्न गाह्रो छ। पृष्ठको लागि भाषा निर्दिष्ट गर्न, HTML ट्यागमा ‘lang’ विशेषता थप्नुहोस्। उदाहरणका लागि: html lang=ne

Paragraph in the Garhwali language (lang=”hi”).

Using lang=”hi” becuase Garhwali, being a regional language, does not have a specific two-letter or three-letter code assigned in ISO 639-1 or ISO 639-2 standards.

यदि कोई भाषा निर्दिष्ट नहीं है, तो स्क्रीन रीडर पृष्ठ को उपयोगकर्ता की डिफ़ॉल्ट भाषा में पढ़ेगा। इसका परिणाम खराब लहजे में हो सकता है जिसे समझना मुश्किल है। पृष्ठ के लिए एक भाषा निर्दिष्ट करने के लिए, HTML टैग में ‘लैंग’ विशेषता जोड़ें। उदाहरण के लिए: html lang=hi.

The key to getting NVDA to speak non-Latin languages is to switch to voice synthesizer like eSpeak NG that is more multilingual. It can be done under Preferences > Settings > Voice > synthesizer. The default MS OneCore voices sound good for American English but don’t support a lot of other languages. ERNET India has directions on how to get NVDA to speak Hindi. eSpeak NG also has a Nepali voice you can switch to in the NVDA speech settings.

Resources

ISO 2 Letter Language Codes reference

Google Translate

ISO 639.2 Codes for the Representation of Names of Languages

Drupal page accessibility for site editors

by

TOC

Checking your Drupal page for accessibility:

  • To test your Drupal 10 page for accessibility, first get the WAVE extension for your browser. It’s available for: Chrome, Firefox, and Edge. WAVE powers Ohio State’s PopeTech accessibility report generator. With the browser extension you’ll be able to test a page with one-click.
  • To start checking a page with WAVE, go to URL of the page in a browser where you’re not logged. If you use WAVE while you’re logged into Drupal, you may get false positives related to the administrative interface. You might choose to edit the page in one browser while testing it with WAVE in another.
  • Press the WAVE button and start reviewing the results.
  • Press the Details tab to see what errors and alerts were found. Errors tend to be more serious, objective problems, while alerts may be more subjective. WAVE will also let you know if your page has Contrast Errors.
  • Click on an error icon and the click ‘Reference’ to learn more about the error and how to fix it. WAVE will tell you why the error matters and about the algorithm it used to find it. Occasionally you may notice an alert is actually a false positive.
  • To actually fix an error, determine if the error in an editable area of your Drupal page. Content coming after the page’s primary heading H1 may be in the editable area. If the error isn’t in the editable area, but is in the frame around it (the website theme), contact your web developer or your helpdesk for web update requests.
  • Log into to Drupal in another browser to begin fixing the error. Note the location where the error is happening.

Common types of WAVE errors that can be fixed in the editable area of a Drupal page:

  • Skipped heading level alerts – to fix the heading structure you’ll need to select the headings in the Drupal editor where a level is skipped and change them to the appropriate level to nest directly under the next highest level. WAVE has a Structure tab that can show you the next highest level in the headings structure so you’ll know which to change the skipped ones to.
  • Images missing alt text – click on the image and enter alt text description related for the purpose of the image.
  • Empty headings – empty headings (with no text in them) sometimes are accidentally used as a spacer between paragraphs. To fix, backspace and delete where the empty heading is or select and delete it. If you still want the space you could select the empty heading and change it to a normal paragraph in the Drupal editor.
  • Empty links – Sometimes a graphic or icon will be used as a link but have no accessible name (no actual link text or alt tag). When that happens, it’s known as an ‘empty link’. To fix an empty link, give it’s image some alt text related to the purpose of the link or include link text. You may need to switch to the source code view in the Drupal editor to find where to insert the link text in the <a> tag. Insert it between the opening and closing parts of the <a> tag.

If you have questions about WAVE, check their frequently asked questions help page.

Test of changing the role of a span in a menu

by

This is a test of changing the role of a span to fix an accessiblity issue.

Creating link text intended for screen reader users that is hidden visually

by

TOC

In some cases, developers may want to create links that are only intended for screen reader users, that are hidden visually. There are two ways to create visually hidden links:

  • The aria-label method
  • The clip method

One case where you might want to have visually hidden links is the case of social media icons. For example, visually you might want to show a Facebook logo for the link, but screen reader users you would spell out the word ‘Facebook’ in the link. So, it would appear as a Facebook logo button, but have an accessible name of ‘Facebook’.

The aria-label method

Aria-label is the attribute that can change the accessible name of a link. In this method, a CSS class is placed in the <a> tag to visually show the Facebook icon, like class=”fb”. Then the aria-label attribute is used in the <a> tag to provide an accessible name. Without aria-label in it, it would be an empty link.  
Aria-label code example:

  <a href="https://www.facebook.com/stateuniversity"  class="fb" aria-label="State University Facebook  page"></a>

The clip method

In the clip method, the text that’s desired to be visually hidden is wrapped in a <span> and given a CSS class, like: class=”visually hidden”. Then in that CSS class definition, the text is thrown off-screen, so it’s not seen visually, but remains available for screen reader users. It’s called the clip method because it uses the clip CSS property to redefine the visible portion of the link element and totally clip it from being seen.
Clip method code example:

  <a href="https://www.facebook.com/stateuniversity"  class="facebook_icon">

  <span  class="visually-hidden">State University Facebook  page</span>

  </a>

Some CSS for the code example:

  <style> …

  .visually-hidden {

  border: 0;    clip: rect(0 0 0 0);

  height: 1px;    margin: -1px;

  overflow: hidden;    padding: 0;

  position: absolute;   width: 1px;

  }

  </style>

Updated clip method CSS

The MDN docs say that the clip CSS property is now deprecated. Here is the CSS updated to use the clip-path method:

  <style> …

  .visually-hidden {

  border: 0;    clip-path: rect(0 0 0 0);

  height: 1px;    margin: -1px;

  overflow: hidden;    padding: 0;

  position: absolute;   width: 1px;

  }

  </style>

The clip-path property can also clip with different shapes, other than a rectangle, like: circle, ellipse, and polygon.

 

Resources about creating visually hidden links:

Using role=”presentation” on HTML tables for special cases

by

HTML table example with role=”presentation” on it

In this example, screen readers should not treat the data table as a table because role=”presentation” removes those table semantics. For this technique to work the role=”presentation” has to be in the table element itself, not on a wrapper div. Upon testing, NVDA and Narrator comply and treat it as normal text without saying anything about the table rows or cells. Layout tables are a case where you might use role=”presentation” to make the table not look like a true data table to screen readers.


Railroads in Columbus Union Station table example
Railroad name Years in operation Succesor company
New York Central 1853-1968 Penn Central
Pennsylvania Railroad 1846-1968 Penn Central
Penn Central 1968-1971 (company existed until 1976) Conrail / Amtrak
Norfolk & Western 1838-1982 Chessie System / CSX
Baltimore & Ohio 1830-1972 (name still used until 1987) Norfolk Southern
Chesapeake & Ohio 1869-1972 Chessie System / CSX

For comparision here’s the same table example but with role=”presentation” removed:


Railroads in Columbus Union Station table example
Railroad name Years in operation Succesor company
New York Central 1853-1968 Penn Central
Pennsylvania Railroad 1846-1968 Penn Central
Penn Central 1968-1971 (company existed until 1976) Conrail / Amtrak
Norfolk & Western 1838-1982 Chessie System / CSX
Baltimore & Ohio 1830-1972 (name still used until 1987) Norfolk Southern
Chesapeake & Ohio 1869-1972 Chessie System / CSX

Mapping InDesign Paragraph Styles to Heading Tags

by

To setup heading styles in InDesign you’ll need to define Paragraph Styles in your InDesign document. Penn State has a good article about this. You basically create styles for the heading levels you want to use in your document, such as H1, H2, and H3. You can also setup a regular paragraph style for the <P> tag.

To open the Paragraph Styles panel in InDesign:

  • Go to the Window menu.
  • Choose Styles > Paragraph Styles.

To create a new paragraph style from existing text:

  • Select the text.
  • Choose ‘New Paragraph style’ from the hamburger menu in the ‘Paragraph Styles’ panel.

The font & size attributes of the text you selected become the basis of the new paragraph style.

To check which tag a style is mapped to:

  • Select the style in the ‘Paragraph Styles’ panel.
  • Go to in the ‘Paragraph Styles’ panel hamburger menu and choose ‘Style Options’.
  • Click on the ‘Export tagging’ area. Under ‘PDF’ you will be able to see which style your paragraph style is mapped to. If you want to map it to a Heading Level 1, then choose H1 from the list of tags. If there are not a lot of tags in the list you may need to load your standard paragraph styles from another document and use the ‘Map styles to tags’ function under the Structure area.

To see the tags structure of an InDesign document:

  • Go to the View menu.
  • Go to Structure > Show Structure.

To map your newly created heading paragraph styles to tags in the structure:

  • Go to the hamburger menu in the Structure panel.
  • Choose the ‘Map styles to tags’ option.

If you have a premade set of paragraph styles you want to reuse in the document, you can load them via the ‘Load’ button in the ‘Map styles to tags’ option. This could save time in setting up tags & styles. Some designers keep a separate .indd InDesign file with all their commonly used styles in it to load.

The document structure appears as in a panel on the left side of your screen.

How to create accessible data tables in InDesign

by

TOC

There are a couple things to check to be able to export accessible data tables from InDesign:

  1. Make sure your table has a header row at the top. You can check if it has a header row in the Table Setup options.
  2. Ensure that you export your document as a ‘tagged PDF’.

Also, keep in mind that InDesign can only markup basic tables with column header cells in a top header row. If you need to do a more complex table that also includes row header cells on the left side, you’ll need to add the row header cell markup in Adobe Acrobat Pro.

To create a data table in InDesign:

  • Click in a text where you want the table to go.
  • Select Table > Create Table.

This brings up a dialog that asks how many rows and columns you want in the table. The important part for accessibility is that it asks you to designate one or more header rows. A typical basic table has one header row.

Inserting a table into an InDesign text box.

Be sure to include a header row when insterting a data table into your PDF document.

How to select a table in InDesign and adjust options?

  • Click in the table that you want to adjust.
  • Go to the Table menu in InDesign.
  • Choose Table Options > Table Setup.

A dialog box of table settings comes up where you can adjust settings like the number of rows and you’ll also have the ability to add a header row if your table doesn’t already have one.

Selecting a table and adjusting setup options

Selecting a table and adjusting setup options

How to add a row to a table in InDesign?

  • Click in the row where you want the new row to go above or below.
  • Go to the Table menu in InDesign.
  • Choose Insert > Row.
  • Choose if you want the new row to go above or below the current row and hit ‘Ok’.

The new row appears above or below the current row you were in.

Inserting a row in an InDesign table.

Inserting a row in a data table

How to delete a row in a table in InDesign?

  • Click in the row that you want to delete.
  • Go to the Table menu in InDesign.
  • Choose Delete > Row.

The current row is deleted.

How to delete a row in a table

How to delete a row in a table

To export your PDF document with accessibility features:

  • Go to File > Export and choose PDF format.
  • Hit Save and in the options that come up make sure ‘Tagged PDF’ is checked. This will ensure the tag structure for accessibility is included in the document.
  • Click Export and your tagged PDF is saved ready to review in Acrobat.
Make sure 'Tagged PDF' is checked when exporting.

Be sure sure ‘Tagged PDF’ is checked in the options when exporting your PDF document.

What’s the result in Acrobat tags of including a header row in a data table?

If you want to check that the header row exported made it into your PDF successfully you can:

  • Open the document in Adobe Acrobat Pro and find the table in the Tags panel.
  • Then open the <TR> rows of the table and verify that the first row uses true <TH> header cells instead of regular <TD> header cells.
When you look at the exported table tags in Acrobat, the first row will have true <TH> header cells instead of regular <TD> header cells. Normal rows below it will use regular <TD> header cells.

When you look at the exported table tags in Acrobat, the first row will have true <TH> header cells instead of regular <TD> header cells. Normal rows below it will use regular <TD> header cells.

Running the accessibility checker in Adobe Acrobat will also tell you if there’s a problem with your data tables.

To run an accessibility test in Acrobat Pro:

  • Find ‘Prepare for accessibility’ under ‘All Tools’
  • Click ‘Accessibility Check’, accept the default settings, and click ‘Start Checking’.

The test runs and the results pop up. Any table issues can be found under the Tables section.

How to delete a row in a table

Running the accessibility checker in Adobe Acrobat.

Resources about InDesign and accessibility

Videos about InDesign and accessibility

Other data tables in InDesign resources and tutorials:

More information about InDesign and accessibility:

The trouble with table-based layouts

by

HTML tables aren’t a good choice to use to create columns or layouts in a webpage because they aren’t as responsive to small screens and can cause confusion to screen reader users. Back in the late 1990s a lot of designers used tables for visual layout, but this was later found to be a bad practice because fixed-width table-based layouts didn’t adaptive well to different-sized screens. This layout practice used the HTML <table> element for a use that it wasn’t semantically intended. HTML tables were designed for data grids, from the perspective of semantic structure, so it is better to use them only for that purpose.

How developers can ensure layout tables don’t cause problems for assistive technology

Web developers should take steps to ensure layout tables don’t cause problems for screen reader users. If an HTML table must be used for a layout, the developer should add the role=”presentation” attribute to the <table> element so it’s not confused with a data table. Role=”presentation” tells the screen reader to ignore the semantic table markup and treat it as normal text. The web developer also should not include any of the header markup for data tables in a purely visual layout table. These data table header markup tags to avoid are:

  • The <caption> element
  • The <summary> attribute
  • The <th> element
  • The scope attribute (that goes in a <th> tag)
  • The headers attribute (that goes in a <td> table cell tag)

If data table markup tags are used in a purely visual layout table, screen reader users might expect the table to represent tabular data leading to confusion or a poor user experience. So, if a purely visual layout table must be used the developer should ensure that ARIA is used to make it look like normal text to screen readers. Any purely decorative images used in the table so be marked with null alt text (alt=” “) or hidden from readers with aria-hidden=”true”. Back in the late 1990s, web designers used to use tools like Macromedia Fireworks to slice up webpage visual mockups into layout tables and many time these tables would include a bunch of purely decorative images.

An easy way to avoid the troubles with layout tables is to avoid using them at all. For the modern web CSS (cascading style sheets) is a more robust way to design visual layouts. Once web developers realized web sites would be viewed on devices of many different screen sizes, they began using CSS to create columns, float content, and adapt to different viewport widths. The latest Web Accessibility Guidelines (WCAG 2.1) say that websites should be responsive and including layout tables would likely work against that. According to WCAG guidelines, tables should reflow to fill most of the width of the viewport, without causing any horizontal viewport overflow. On smaller screens it becomes more difficult avoid horizontal scrolling (horizontal overflow).  The WCAG SC that is related to tables and horizontal viewport overflow is 1.4.10 Reflow. This success criterion requires that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for vertical scrolling content at a width of 320 CSS pixels.

How content authors can avoid using tables for layout

As a content author, might craft your blog posts in MS Word documents and you might desire to create a visually interesting layouts using tables in Word. But doing so will introduce some of the same accessibility problems as with using HTML tables for layout in a webpage.  It’s best to paste your content into WordPress blog posts as plain text without MS Word formatting so the conversion to HTML will be more semantically correct, free from accessibility problems. Pasting a table-based visual layout from a Word doc should be avoided because it can introduce accessibility problems into a blog post and lead to poor user experiences for both visual and screen reader users.  Tables aren’t really a valid layout technique in Word documents. They are meant for tabular date (data grids). When publicly shared on the web at public universities, Word docs (and PDFs) are expected to follow WCAG guidelines. So, it’s best to follow accessibility best practices even in our Word documents.

WordPress blog sites may or may not include a table tool in the rich text editor for posts. If your WordPress blog does include a table tool, be sure to use it responsibly. Avoid using the table tool for layout tables unless you have the HTML expertise to markup the table so it doesn’t cause problems for assistive technology. If your blog includes a table tool, it’s best to stick to using it just for data tables. You can ask your department’s web developer to check your data table for accessible markup. It’s possible for rich text editors to create simple accessible data tables but when you get into more complex data tables you’ll have to go to the code view to insert the correct accessible markup. Some more advance table markup that might not be in your rich text editor’s table tool may include:

  • Ability to add the scope attribute (that goes in a <th> tag)
  • Ability to add the headers attribute (that goes in a <td> table cell tag)

Once you get into creating more complex data tables you should probably work with your department’s web developer to make them accessible.  For accessible presentation in websites, sometimes it’s better to split a complex table into two or more simple tables. This makes the data tables easier to understand to screen reader users a more adaptable to different screen sizes (more responsive).