Testing accessibility before development begins: wireframe reviews and annotations

Two common accessibility

problems

Why wireframe reviews are a

solution

What are wireframes & annotations?

How do you do a wireframe

review?

What types of issues will a

review pick up? Examples

Practice exercise Who? You!

WHEN DOES ACCESSIBILITY

TESTING TYPICALLY HAPPEN?

a) Before development

b) During development

c) After development, during testing phase

d) A week before launch

e) After launch

f) All of the above

In your experience, when does

accessibility testing typically occur?

Problem

WE’RE TESTING TOO LATE

Solution

START TO TEST SOONER

Contract

Business Requirements

Wireframes

Visual Design Spec

Application Development

QA

In Production

We can test accessibility at any stage

If you could place a bet on finding

accessibility issues in an app…

WHAT ISSUES WOULD YOU BET ON?

Across your accessibility testing, What

are the issues you almost always see?

The usual suspects

Alt text missing or inaccurate

Headings missing or inaccurate

Form labels

Error presentment

where, when, how

Roles tab set, button,

toggle

States expanded/collapsed selected, disabled

Audio, video, animation cannot be stopped

Notifications & updating content

Problem

ACCESSIBILITY ISSUES ARE

PREDICTABLE

"IT'S NOT A DEFECT IF

IT WASN'T A REQUIREMENT"

And the QA manager said…

1. WE'RE ALWAYS TOO LATE

2. WE SEE THE SAME OLD ISSUES

A modest proposal

REVIEW ACCESSIBILITY IN THE

WIREFRAME STAGE

Two problems

WHAT IS A WIREFRAME?

Before the design or the code

A blueprint or schematic

A website wireframe, also known as a page schematic or screen

blueprint, is a visual guide that represents the skeletal framework of a

website... The wireframe depicts the page layout or arrangement of the website’s

content, including interface elements and navigational systems,

and how they work together.

The wireframe usually lacks typographic style, color,

or graphics, since the main focus lies in functionality, behavior, and

priority of content.

In other words, it focuses on what a screen does, not

what it looks like.

Wireframes can be pencil drawings or sketches on a

whiteboard, or they can be produced by means of a broad array of free

or commercial software applications. en.wikipedia.org/wiki/Website_wireframe

http://en.wikipedia.org/wiki/Website_wireframe

# Accessibility

1.

2.

2.

3.

4.

5.

6.

7.

8.

9.

Wireframe annotations

• Identify accessibility issues and

requirements before build the interface

• Doesn’t need to be perfect

• Can be informal or documented

• Raises more questions than answers

• Adapts to how project uses wireframes

What is a wireframe review?

Extending wireframes for accessibility

Wireframe annotations

FOUR TYPES OF

REVIEW COMMENTS

Content alt text, labels,

instructions (off-screen & onscreen)

Development patterns

Known or simple: tabs, expand/collapse

Complex development tasks

(do-able)

Not accessible as-is We need to talk:

interface changes needed (or an exemption)

# Accessibility

1. Needs alt text (e.g. "back")

2. No alt text needed for any

of the icons to the left of

inputs on this screen

3. No alt text needed for icon

4. No alt text needed

5. Needs hidden/off-screen

label (business to provide)





8. Add/subtract icons need alt

text



• Alt text for icons, images, charts

• Hidden label text

• New or revised onscreen content such as expected data values, instructions or required field messaging

• This content will go into the copy deck for translation and approvals

• Keep in mind the wireframe is not a copy deck and most of the words are placeholders

Off-screen & onscreen content






(do-able)



# Accessibility

1. Button

2. No alt text needed for any

of the icons to the left of

inputs on this screen

3. For screen reader whole

row should act as single

element. No alt text needed

for icon

7. After screen reader user

updates value it needs to be

announced

8. Buttons. Needs to convey if

in disabled state

10. Button

11. Heading

12. Is role a radio or a tab? Must

convey selected/checked

• Headings & levels

• Buttons vs. links

• Data tables

• Disabled elements

• Tabs, Radio buttons, checkboxes

• Collapsed/expanded content

• Live regions (updates w/o screen load)

• All the things WCAG says must be pragmatically determined

Identify known accessibility

development patterns






(do-able)



# Accessibility

1. Calendar will need special

attention from development

team.

• Calendars

• Maps

• Carousel

• Audio/video player

• Custom camera

• Timers

Complex interactions or elements






(do-able)



# Accessibility

1. No mechanism for captions

1

# Accessibility

1. We need to talk

2. No really. If you can make this

accessible I will buy you all lunch

1 2

• Expected data format if triggers error

• Missing instructions, required field

• Media or carousel that cannot be paused (no controls)

• Video without "CC" option (unless will be open captioned)

• Interactive charting

• Complex maps

• Complex games

Not accessible in current state

Annotation tips What to avoid writing

Needs alt text What the alt text should be

Needs a hidden label What the label should say

Needs consistent heading Should be <h1>

This is a tabset, a button How to code it

Missing X functionality

(e.g. pause/play)

How to code it

Pattern complex, needs

discussion with developers

Write a mini-tutorial in the

wireframe

X element not accessible Use Y instead of X

Assume readers have some

accessibility experience

Teaching Accessibility 101 in

the annotations

Identify issues and options, don't write solutions

A classic wireframe does not include:

• visual design decisions (such as colours, fonts, positioning, images)

• technical decisions

• Final "copy". All text is subject to change. Labels and instructions, headings cannot be reviewed with much certainty.

Checks related to design, code, copy need to happen later in the project.

What you cannot review in a wireframe

LET'S REVIEW A WIREFRAME!


instructions (off-screen &

onscreen)


Known or simple: tabs,

expand/collapse


(do-able)

Not accessible as-is

# Accessibility

1. Needs alt text

2. Needs alt text

3. Needs alt text

4. Heading

5. Heading

6. Heading

7. Needs dynamic alt text depending

on weather. This will need special

attention from development team

8. How the n 10 days of icons reads

must be logical. Solution will

need discussion

9. Graph. Will need to discuss

approaches with development

Summary of findings for exercise


instructions (off-screen &

onscreen)


Known or simple: tabs,

expand/collapse


(do-able)

Not accessible as-is

Project thinks about accessibility

early

Catch potential issues before development

A head start on content

Identify accessibility development

patterns

Identify complex accessibility interactions

Better requirements for designers,

developers, QA

Goals of a wireframe review

QUESTIONS & COMMENTS

Testing accessibility before development begins: wireframe reviews and annotations

Technology

Transcript of Testing accessibility before development begins: wireframe reviews and annotations