Upload
aidan-tierney
View
512
Download
1
Tags:
Embed Size (px)
Citation preview
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
# 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)
6. Needs hidden/off-screen
label (business to provide)
7. Needs hidden/off-screen
label (business to provide)
8. Add/subtract icons need alt
text
9. Needs hidden/off-screen
label (business to provide)
• 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
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. 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
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. Calendar will need special
attention from development
team.
• Calendars
• Maps
• Carousel
• Audio/video player
• Custom camera
• Timers
Complex interactions or elements
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. 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!
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
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
# 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
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
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