Posts

Mobile app accessibility

by

TOC

While most all WCAG SCs apply to mobile apps there are some that especially apply. This article lists those success criteria and outlines how to test for them. Results of manual testing the SCs can be recorded in a manual testing log as part of a conformance methodology.

WCAG SCs are related to mobile apps

The Web Content Accessibility Guidelines (WCAG) 2.1 include several success criteria (SCs) specifically aimed at improving mobile app accessibility. The WCAG SCs are related to mobile apps are:

  1. Orientation (SC 1.3.4): Content should not be restricted to a single display orientation unless essential. This means users should be able to switch between portrait and landscape modes without losing functionality.
  2. Reflow (SC 1.4.10): Content should be presented without loss of information or functionality, and without requiring scrolling in two dimensions for vertical scrolling content at a width equivalent to 320 CSS pixels.
  3. Pointer Gestures (SC 2.5.1): All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture.
  4. Label in Name (SC 2.5.3): For user interface components with labels that include text or images of text, the accessible name should contain the text that is presented visually.
  5. Motion Actuation (SC 2.5.4): Functionality operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental activation.

These criteria help ensure that mobile apps are accessible to users with various disabilities, including those who rely on different input methods or need adaptable content presentation.

How to test Orientation (SC 1.3.4) in mobile apps?

Testing for Orientation (SC 1.3.4) in mobile apps involves ensuring that the app’s content and functionality are accessible and usable in both portrait and landscape modes. Here are some steps to help you test this:
Manual Testing:

    • Rotate the Device: Open the app and rotate the device between portrait and landscape orientations. Check if the content reflows properly and remains accessible.
    • Check for Consistency: Ensure that all interactive elements (buttons, links, forms) are still usable and visible in both orientations.
    • Look for Clipped Content: Verify that no content is cut off or hidden when switching orientations.

How to test Reflow (SC 1.4.10) in mobile apps?

Testing for Reflow (SC 1.4.10) in mobile apps ensures that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions. Here are some steps to help you test this:
Manual Testing:

    • Zoom In: Open the app and zoom in to 400%. Check if the content reflows within the viewport without requiring horizontal scrolling.
    • Check for Clipped Content: Ensure that no content is cut off or hidden when zoomed in.
    • Responsive Design: Verify that the app uses responsive design techniques, such as CSS media queries, to adjust the layout for different viewport widths.

How to test Pointer Gestures (SC 2.5.1) in mobile apps?

Testing for Pointer Gestures (SC 2.5.1) in mobile apps ensures that all functionality using multipoint or path-based gestures can also be operated with a single pointer without a path-based gesture. Here are some steps to help you test this:
Manual Testing:

    • Single Pointer Operation: Try to perform all actions using a single pointer (e.g., one finger or a stylus). Ensure that any functionality requiring multipoint or path-based gestures can also be achieved with a single tap, click, or similar action.
    • Alternative Methods: Check if there are alternative methods provided for actions that typically require complex gestures. For example, if an action requires a two-finger swipe, ensure there is a button or single-tap alternative.

How to test Label in Name (SC 2.5.3) in mobile apps?

Testing for Label in Name (SC 2.5.3) in mobile apps ensures that the accessible name of user interface components matches the visible label. Here are some steps to help you test this:
Manual Testing:

    • Inspect Elements: Use the accessibility inspector in your development environment (e.g., Xcode for iOS, Android Studio for Android) to check the accessible names of UI components. Ensure that the accessible name contains the visible text.
    • Voice Control: Use voice control features (e.g., Voice Control on iOS, Google Assistant on Android) to interact with the app. Verify that commands using the visible labels work as expected.

Testing for Motion Actuation (SC 2.5.4) in mobile apps?

Testing for Motion Actuation (SC 2.5.4) in mobile apps ensures that functionality triggered by device motion can also be operated by user interface components, and that motion-based actions can be disabled to prevent accidental activation. Here are some steps to help you test this:
Manual Testing:

    • Device Motion: Identify all functionalities that rely on device motion (e.g., shaking, tilting). Test these actions to ensure they can also be performed using standard UI components like buttons or switches.
    • Disable Motion: Check if there is an option to disable motion-based actions within the app settings. Verify that disabling motion does not hinder the app’s functionality.

Other tools and methods

Other forms of testing and tools that you can use to evaluate mobile apps include:
Automated Testing Tools:

    • Use tools like Appium or Espresso to automate the testing of motion-based functionalities. These tools can simulate device motions and verify if alternative methods are available.

Accessibility Testing Tools:

    • Tools like Accessibility Scanner (for Android) or VoiceOver (for iOS) can help identify issues related to motion actuation and ensure that the app remains accessible.

User Testing:

    • Involve users with motor impairments to test the app. Their feedback can provide valuable insights into any accessibility issues that might not be apparent through automated or manual testing alone.

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: