Accessibility as a Service

Tips & Tricks for Testing Accessibility with Assistive Technologies

There are many ways to perform testing for accessibility, each one with their own strengths and weaknesses. Testing with assistive technologies is a great way to get a clear understanding of how your system behaves for real users – assuming that the tester is able to effectively use the assistive technologies they’re testing with. As a kickoff point, here are some valuable tips and tricks we’ve discovered during our own testing experiences.

Continue reading “Tips & Tricks for Testing Accessibility with Assistive Technologies”

Mortise Test Per Week: If multi-point or path-based pointer gestures are used, ensure that a single-pointer non-path alternative is provided.

LANG-21: If multi-point or path-based pointer gestures are used, ensure that a single-pointer non-path alternative is provided.

How to test

  • Identify instances of functionality that requires multi-point or path-based pointer gestures.
  • Confirm that that functionality is also available by another means which does not require such gestures.

Exceptions

  • A multi-point or path-based gesture is essential (e.g. providing a signature on a touch screen).

How to fix

Provide an additional mechanism for every complex gesture (e.g. supplement pinch and zoom with keyboard accessible zoom buttons).

Related Standard: 2.5.1 A

This is one in a series of posts highlighting one of more than 270 accessibility tests in Mortise.io. Come back next week for more!

Mortise Test Per Week: Ensure custom sliders follow the defined interaction pattern(s).

ARIA-11: Ensure custom sliders follow the defined interaction pattern(s).

How to test

  • Identify instances of single-thumb sliders.
  • Assess their semantics and interactions and confirm that they follow the applicable Slider pattern (https://www.w3.org/TR/wai-aria-practices/#slider).
  • Assess whether the expectations conveyed by their design match the pattern they use (i.e. that they look like what they are).
  • Identify instances of multi-thumb sliders.
  • Assess their semantics and interactions and confirm that they follow the applicable Slider (Multi-Thumb) pattern (https://www.w3.org/TR/wai-aria-practices/#slidertwothumb).
  • Assess whether the expectations conveyed by their design match the pattern they use (i.e. that they look like what they are).

Exceptions

None

How to fix

Re-implement this widget to follow either the Slider pattern (https://www.w3.org/TR/wai-aria-practices/#slider) or the Slider (Multi-Thumb) pattern (https://www.w3.org/TR/wai-aria-practices/#slidertwothumb) that’s applicable to the design and functionality.

Related Standard: 1.3.1 A and 4.1.2 A

This is one in a series of posts highlighting one of more than 270 accessibility tests in Mortise.io. Come back next week for more!

Important change to API2 contract

There is an important, breaking change coming soon to the contract for Version 2 of our Test API that we want to alert users to regarding the callbackUrl parameter.

Per the current documentation, callbackUrl is “(an)URL at which results will be POSTed to when testing has been completed”. Real-world usage shows that this feature could be improved and, while we normally avoid breaking changes, we’ve decided to do so in this case in order to avoid confusion for future users of the API. The following details what will be changed:

  1. The callback will be run twice: when the initial POST is made to the API and when the accessibility testing is complete. (Though not documented, this is happening now)
  2. callbackUrl is going away and will be replaced with callback
  3. callback must be an object. For example:

    "callback": {
        "url": "http://www.foo.com",
        "method": "POST",
        "headers": {
            "X-My-Header": "Value here"
        }
    }
    

  4. callback, if supplied, must be an object. If it isn’t an object, the API will return a 400 response
  5. callback, if supplied, must contain url. All other properties
    are optional
  6. If callback.method is not supplied, it will default to POST
  7. callback.method will support POST, PUT, PATCH, and DELETE methods.
  8. If Content-Type header is not supplied, we will default it to application/json

If you’re currently using callbackUrl in your API2-consuming code, the only thing you need to change is:

Before:
"callbackUrl": "https://foo.com"
After:
"callback": { 
    "url: "https://foo.com"
}

We anticipate that these changes will be deployed to production in one week, however the timeline depends on changing some of our own existing code for other parts as well in order to support this. To be notified when these changes are deployed to production, give us a shout at talktous@tenon.io

Mortise Test Per Week: Ensure link text and navigational graphics/icons are used consistently across pages (e.g. the same icon always goes to the same destination or serves the same purpose).

NAVIGATION-04: Ensure link text and navigational graphics/icons are used consistently across pages (e.g. the same icon always goes to the same destination or serves the same purpose).

How to test

  • Browse through multiple pages within the site or application.
  • Assess whether global navigation, other linked text, and non-text navigation controls, are used consistently.

Exceptions

  • Graphics are used consistently but not identically (e.g. a print icon might be “Print receipt” in one place but “Print invoice” in another, which is not identical, but is functionally consistent).

How to fix

Ensure that when the same interactive text is used, it always represents the same function or navigates to the same destination. Ensure that icons and other interactive graphical elements are used consistently, so that the same graphic always represents the same or closely-similar function.

Related Standard: 3.2.4 AA

This is one in a series of posts highlighting one of more than 270 accessibility tests in Mortise.io. Come back next week for more!

Start your free trial of Tenon today!