Introduction DEV UX EDITOR CJE

Preface

Functional testing for Inclusive Design

The accessibility features and basics of how to functional test content using heuristic analysis, tools and screen readers are covered here for Web, Android and iOS.

Basic testing steps:

  1. Visual Inspection
  2. Page Structure
  3. Composed Widgets

Process steps:

At each step you'll perform the following actions.

1. Heuristic analysis
At this first step you'll start guessing what the functional expectation is. Identify what you see, what should be read aloud, what should happen step-by-step, and how this should be constructed. DON'T use a mouse, keyboard or other input method yet. In principle this information must already be present at the Design Annotation fase.
2. Write down possible focus points
For each focus point where you're not sure if this is done properly put it on paper:
  • Name and place
  • Focus point and expected result
3. Start inspection
Next we start the actual inspection. For latin languages this means we start from top to bottom and from left to right. We will use the tab key on the keyboard, see what will happen when we use the mouse and with screen readers we'll use the left and right arrow keys on a keyboard or swipe left and right with a mobile device. Tools will be used to support the inspection. Is everything communicated as expected and logical?
4. Annotate failures
When the result is NOT what's expected, note the possible fail. Please make sure it's clear which part may have a fail, where this exactly happens, under which conditions, and how to reproduce.

Test Procedures & Results:

At each step you'll find the most common accessibility checkpoints with a short explanation on what's expected. When not sure on how to test these, there are links for each checkpoint at the "Test Procedures & Results" sections where you'll be taken to the guideline with an explanation on how to test.

1 Visual Inspection

What you see is what everyone should get

On basis of the visual appearance you'll start guessing what the functional expectation is. Identify what you see, what should be read aloud, what should happen step-by-step, and how this should have been constructed.

Essential content communicated visually MUST be heard by a screen reader. Thoroughly examine the visual design, states and processes using different input methods.

  • Focus

    • All interactive elements must be focusable and inactive elements must not be focusable.
    • When focused, all actionable and focusable elements must have a visible state change.
    • Content order must be logical.
    • Actionable content must be navigable in a meaningful sequence.
    • Alternative input methods must be supported.
  • Consistency

    • Links in different places referring to the same page are identified consistently.
    • The look and sound of a control, object or element should inform the user how to interact with it.
    • Unless there is a recognised convention, such as for navigation, do not use links that are styled to look like buttons.
  • Responsive / Content resizing

    • Users must be able to control font sizing
    • Interface (UI) scaling must be possible.
    • All breakpoints of responsive design must be tested by changing viewport size or zoom.
    • Reflow of content is presented without loss of information or functionality.
  • Color / Contrast

    • Information or meaning must not be conveyed by colour only.
    • The colour of text and background content must have sufficient contrast.
    • The colour of interactive components and background must have sufficient contrast.

2 Page Structure

Well-structured content enables more efficient navigation and provides simular experiences for everyone

Looking at a page provides lot's of clues about it's structure and relationships. This enables to quickly judge the content and focus on the parts we're interested in.

All these clues must also be present in a similar way in the code so everyone can experience this. The functional outcome of this structure can easily be tested with a screen reader.

  • Containers and Landmarks

    • Containers should be used to describe page/screen structure, as supported by the platform.
    • Use ARIA landmark roles or HTML5 sectioning elements to describe document structure and outline different parts of the page.
  • Unique Titles and Headings

    • All pages or screens must be uniquely and clearly identifiable.
    • Content must provide a logical and hierarchical heading structure, as supported by the platform.
  • Links Vs. Buttons

  • Lists, Tables and Semantics

    • Visual formatting alone must not be used to convey meaning.
    • Provide non-visual alternatives, such as semantic code, hidden text or accessibility labels.
  • Images and Text equivalents

    • Images of text should be avoided.
    • Alternatives must briefly describe the editorial intent or purpose of the image, object, or element.
    • Decorative images must be hidden from assistive technology.
    • Visual formatting alone must not be used to convey meaning.

3 Composed Widgets

Composed widgets define how the outcomes from its atomic components are aggregated into a single outcome

When multiple small components are responsible for a single user experience and function we should carefully test them in a linear and dynamic flow.

The grouping must be clear, the focus management must be logical and dynamic updates must communicated for everyone at all times. Never deviate from known patterns for personal gain or preferences. Don't be in the delusion you're able to adjust global conventions.

Examples for composed widgets are: Menu's, Sub-Menus, Modals, Carousels, Datepickers, Sliders, Collapsibles, Combo Boxes, Expanding Accordians, Error Messaging and more.

  • Standards and Global conventions

    • Make sure if there is a standard or specification to apply and test it accordingly, never try to make your own standard.
    • If no standard is present is there a global convention to follow?
    • When in doubt check the W3C, Apple, Microsoft or Google like companies and their apps as they will most likely be accessible.
  • Atomic rules

    • A step-by-step funtional check for each isolated component
    • Atomic components test a specific, isolated type of solution.
    • It contains a precise definition of what needs to be tested and when to fail.
    • Meaning that atomic rules test a single "failure condition", and do so without using results from other (composed) rules.
    • An example is a "next" button in a pagination which can be tested in isolation.
  • Composed rules

    • Every group of controls is labeled.
    • A combined check for all options and information in a functional way.
    • Composed rules test results from multiple atomic components working together
    • They should be used to decide if an accessibility requirement was failed.
    • When entering the composed widget, is it clear for everyone what it is?
    • In a linear flow all options must be tested in a step-by-step approach.
    • Focus on timing, values, boundaries and relationships.
    • Current elements must be communicated as well as visual updates for ALL users
    • Results must be clearly communicated, also for screen readers as well as when the task is finished
    • When in error, is it logical to ALL users what the error is, where to find it and how to fix it?

Process steps:

  • 3.1 Heuristic analysis
  • 3.2 Write down possible focus points
  • 3.3 Start inspection
  • 3.4 Annotate failures