Early prevention of accessibility issues with mockup & wireframe reviews

We can review accessibility at any stage

Contract/SOW

Business Requirements

Mockups & Wireframes

Visual Design Copy deck Development

QA User testing

In Production

(audits, complaints)

Purpose of reviewing mockups & wireframes

• Identify defects

– Will need to modify interface

• Identify requirements to avoid defects

• Reduce overall effort

– Less defects

– Quicker QA

– Quicker fixes

– Less last-minute panic

ACCESSIBILITY ISSUES ARE

PREDICTABLE

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

WHAT IS A WIREFRAME OR MOCKUP?

Before the design or the code

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

A blueprint or schematic

Annotations

# Accessibility

1.

2.

2.

3.

4.

5.

6.

7.

8.

9.

4 types of annotations

• 3 relate to predicting & avoiding issues

• 1 relates to identifying actual issues that

require a change

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



Off-screen & onscreen content

• 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






(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

Identify known accessibility

development patterns

• 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 programatically determined






(do-able)



# Accessibility

1. Calendar will need special

attention from development

team.

Complex interactions or elements

• Calendars

• Maps

• Carousel

• Audio/video player

• Custom camera

• Timers






(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

Not accessible in current state

• No expected data format (if triggers error)

• Missing instructions, required fields

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

• Video (synchronized) without "CC" option, unless open captioned

• No transcript link

• Complex interactive charts

• Complex maps

• Complex games

Identify issues and options, don't write solutions

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

What you cannot review in a wireframe

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.

LET'S REVIEW A WIREFRAME!


instructions (off-screen &

onscreen)


Known or simple: tabs,

expand/collapse


(do-able)

Not accessible as-is

Summary of findings for exercise

# 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 10 days of icons reads

must be logical. Solution will

need discussion

9. Graph. Will need to discuss

approaches with development

Goals of a mockup/wireframe review

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

No need to be perfect.

Anything you can prevent now is better than later!

QUESTIONS & COMMENTS

Early prevention of accessibility issues with mockup & wireframe reviews

Technology

Transcript of Early prevention of accessibility issues with mockup & wireframe reviews