Category: Mortise Test Per Week

Mortise Test Per Week: Do not use nested data tables.

By Karl Groves |

TABLES-09: Do not use nested data tables.

How to test

  • Use devtools to confirm that the page does not contain any nested data tables.

Exceptions

1. If the tables are presentational, are correctly marked-up with `role=”presentation”`, and do not have captions, headers, or other data markup.

How to fix

Remove any nested tables. Evaluate how to present the data without requiring nesting of tables.

Related Standard: 1.3.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: Provide more than one way to locate a web page in a set of pages.

By Karl Groves |

NAVIGATION-08: Provide more than one way to locate a web page in a set of pages.

How to test

  • Determine whether the site has either a search facility or a sitemap, which is available or linked-to on every page.
  • Assess whether all the site content can be found using one of these methods.

Exceptions

  • Pages that can’t be directly accessible for security reasons (but if some pages require login status, these pages should still appear in search results or the sitemap when the user is logged-in, unless there’s a clear reason not to).
  • Pages that can’t be directly accessible because they’re steps within a process (e.g. pages within a checkout flow).
  • Search results pages that can’t be directly accessed without performing a search.
  • Very small sites in which every page is linked from every other page.

How to fix

Implement a search facility or sitemap to make it easier for users to find individual content pages within the site. This should be available or linked-to on every page.

Related Standard: 2.4.5 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!

Mortise Test Per Week: Ensure drag and drop is accessible to keyboard users, and that an alternative is available for assistive technology users.

By Karl Groves |

ARIA-10: Ensure drag and drop is accessible to keyboard users, and that an alternative is available for assistive technology users.

How to test

  • Identify instances of drag and drop interfaces.
  • Confirm that all interaction stages (selecting, moving, dropping) are accessible to keyboard users.
  • Confirm that an alternative interface is also available (i.e. a means of achieving the same functionality which is accessible to assistive technology).

Exceptions

None

How to fix

Drag and drop can be made accessible to keyboard users, by providing Tab access to the draggable elements and their containers, and defining intuitive keystrokes for selecting and dropping the elements. An example of keyboard accessible drag and drop can be found at https://brothercake.com/reference/drag-and-drop Drag and drop cannot be made accessible to assistive technologies, because the semantics to describe their roles and states were deprecated in ARIA 1.1, and were never fully implemented anyway. Therefore an alternative interface must also be provided, which is accessible to assistive technologies; this does not need to be dynamic in the same way, it simply needs to allow users to achieve the same end result.

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!

Mortise Test Per Week: If pauses in a video are insufficient for audio descriptions, extended audio description is provided.

By Karl Groves |

MEDIA-06: If pauses in a video are insufficient for audio descriptions, extended audio description is provided.

How to test

  • Review video content in which there are not enough pauses in the audio to insert an audio description, and confirm that extended audio descriptions are available in this case.

    • Exceptions

    • Where the video already has complete audio description that does not require extended audio description.
    • Where an alternative version of the video is available which meets the criteria of this test.

    How to fix

    Provide extended audio descriptions for the video, in which the video content is paused while the audio descriptions play, so that the audio descriptions do not conflict with the existing audio content. This may mean providing an alternative version which has extended audio descriptions built-in, or use a video player which supports switchable extended audio descriptions.

    Related Standard: 1.2.7 AAA

    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: Do not open new windows, switch user agents, or move focus, without user notice.

    By Karl Groves |

    NAVIGATION-10: Do not open new windows, switch user agents, or move focus, without user notice.

    How to test

    • Identify any instances of new windows which are opened without user notice.
    • Identify any instances of external applications which are opened without user notice.
    • Identify any instances of programmatic focus management, and assess whether this is necessary, expected, and obvious.

    Exceptions

    • Where programmatic focus changes are necessary and expected within an interactive context, and it’s clear to the user that this has happened (e.g. a button to open a datepicker moves focus to the datepicker, and this focus change is visually obvious and announced to assistive technologies).
    • Changes of content are not necessarily changes of context (e.g. opening a dropdown menu changes the content but does not change the context).

    How to fix

    Links or buttons which open new windows or external applications should pre-warn the user that this will happen. Links which open new windows, for example, can have an icon which visually denotes this behaviour, accompanied by accessible text which says “link opens in a new window” or similar. However ideally, it’s best not to open new windows at all. Programmatic focus changes should only be performed when they are necessary (for usability) and expected, and it’s obvious to users that this has occurred (e.g. a button to open a datepicker moves focus to the datepicker, and this focus change is visually obvious and announced to assistive technologies).

    Related Standard: 3.2.2 A and 3.2.5 AAA

    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!

    Sign up now