-
Jennifer Mankoff authoredJennifer Mankoff authored
best-practices.html 14.40 KiB
---
layout: presentation
title: Best Practices --Week 4--
description: Best Practices for Building Accessible Apps
class: middle, center, inverse
---
background-image: url(img/people.png)
.left-column50[
# Week 3: Building For Accessibility
{{site.classnum}}, {{site.quarter}}
]
---
name: normal
layout: true
class:
---
# Important Reminder
## This is an important reminder
## Make sure zoom is running and recording!!!
---
[//]: # (Outline Slide)
# Learning Goals for Today
**Who Is Responsible for Accessibility?**
How Screen Readers Work
Building for Accessibility
- Structure impacts navigation order
- Need to announce things that change
---
[//]: # TODO expand this slide deck? IT's short and could cover more. Also discuss how this should impact the report
# Why isn't the World Already Accessible?
Designing for accessibility is hard
Implementing accessibility is hard
Testing accessibility is also hard!
---
# Who Creates Accessibility?
**Organizations impact accessibility**
Designs have a big role in what is accessible
Programmers also of course very important
These days, a lot of it is created by end users
---
# Who Creates Accessibility?
Organizations impact accessibility
**Designs have a big role in what is accessible**
Programmers also of course very important
These days, a lot of it is created by end users
---
# How might UX Designers address Accessibility
Include it in design requirements
Provide ALT text for images and buttons
Provide guidance for both nonvisual and visual structure (e.g. proper linear order)
---
# Who Creates Accessibility?
Organizations impact accessibility
Designs have a big role in what is accessible
**Programmers also of course very important**
- Need to understand the expectations of APIs and accessibility technologies
- Need to understand screen readers
These days, a lot of it is created by end users
---
[//]: # TODO fill in
# What do Programmers already know about access?
[Accessibility in Software Practice](https://dl.acm.org/doi/pdf/10.1145/3503508)
???
Summarize this more...
---
[//]: # TODO fill in
# Organizational Issues
<!-- --- -->
<!-- # How might Designers address Accessibility -->
<!-- <iframe src="https://embed.polleverywhere.com/free_text_polls/sL5v5Ufo0sHFBmmC15MPV?controls=none&short_poll=true" width="800px" height="600px"></iframe> -->
---
# Who Creates Accessibility?
Organizations impact accessibility
Designs have a big role in what is accessible
Programmers also of course very important
**These days, a lot of it is created by end users**
- This means that you have to think about *indirect* impacts on content creation too (i.e. what do you expose to end users in authoring tools)?
- Will talk more about this next week, but crowdsourcing & online social networks part of this too
---
[//]: # (Outline Slide)
# Learning Goals for Today
Who Is Responsible for Accessibility?
**How Screen Readers Work**
Building for Accessibility
- Structure impacts navigation order
- Need to announce things that change
---
# (On-desktop) screen reader interaction
Three core interaction patterns:
- Linear navigation through like objects- Hierarchical navigation through logically related objects
- Switching between object types
---
# (On-phone) screen reader interaction
.left-column[
]
.right-column[
Three core interaction patterns:
- Swipe to navigate linearly
- Touch to navigate spatially
- The first “hit” of an interface element will focus, double tap to select/activate that interface element
]
???
Discuss similarities and differences from desktop
---
# Screen Readers
.left-column-half[
Different types of screen readers.
- JAWS for Windows
- NonVisual Desktop Access
- VoiceOver
- TalkBack
- ChromeVox
]
.right-column-half[
 
*Where can you find one?*
Different devices used to interact with screen readers.
]
---
# Building for screen readers (1 of 2)
Screen readers get underlying information about controls from operating systems.
- This information must be provided by the developer (and in some cases, parts of the info provided by toolkit library)
- Accessibility APIs provide the information to a screen reader.
- Screen readers provide this information visually, through audio or in Braille to users.
---
# Building for screen readers (2 of 2)
<DIV class="mermaid">
graph LR
SR[fa:fa-volume-up <BR> Screenreader<BR>]:::bluelarge -->|Asks for next object| API(fa:fa-codepen<BR> Accessibility API<BR>):::bluelarge
API -->|Passes along request| ATK[<BR> Toolkit<BR>]:::bluelarge
ATK -->|Checks Details| App[fa:fa-mobile <BR>App<BR>]:::bluelarge
App -->|Name: Foo| ATK
ATK -->|Name, Role: Button| API
API -->|Name, Role| SR
Speak(fa:fa-volume-up Button, Foo ):::bluelarge
</div>
--
... (repeat for each swipe)
<DIV class="mermaid">
graph LR
SR[fa:fa-volume-up <BR> Screenreader<BR>]:::bluelarge -->|Asks for next object| API(fa:fa-codepen<BR> Accessibility API<BR>):::bluelarge
API -->|Passes along request| ATK[<BR> Toolkit<BR>/Browser]:::bluelarge
ATK -->|Checks Details| App[fa:fa-mobile <BR>App<BR>]:::bluelarge
App -->|Name: Bar| ATK
ATK -->|Name, Role: Button| APIAPI -->|Name, Role| SR
Speak(fa:fa-volume-up Button, Bar ):::bluelarge
</div>
---
# What happens when user double taps to invoke?
<DIV class="mermaid">
graph LR
SR[fa:fa-volume-up <BR> Screenreader<BR>]:::bluelarge -->|Invokes object| API(fa:fa-codepen<BR> Accessibility API<BR>):::bluelarge
API -->|Passes along request| ATK[<BR> Toolkit/<BR>Browser]:::bluelarge
ATK -->|Invokse Callback| App[fa:fa-mobile <BR>App<BR>]:::bluelarge
App -->|Updates Interface<BR>Announces Changes| ATK
ATK -->|Passes along information| API
API -->|Deleted text| SR
Speak(fa:fa-volume-up Deleted Text ):::bluelarge
</div>
---
# API specific issues Impact Access
You always must to understand your accessibility API in depth to make an app accessible
For example, when [Ross et al, 2017](https://dl.acm.org/doi/10.1145/3132525.3132547) studied 1000s of android apps, some common errors came up which aren't in guidelines because they are either tool specific or straight up UX errors:
| | Description|
|--|
|<i class="darklight fa fa-strikethrough fa-2x"></i> | TextView has a content description. This might interfere with a screen reader’s ability to read the content of the text field |
| <i class="darklight fa fa-angle-double-right fa-2x"></i> | Overlapping clickable items |
|<i class="darklight fa fa-link fa-2x"></i> | URL in link may be invalid |
---
[//]: # (Outline Slide)
# Learning Goals for Today
Who Is Responsible for Accessibility?
How Screen Readers Work
Building for Accessibility
- **Structure impacts navigation order**
- Need to announce things that change
---
# Key Navigation Concept
Reaching times
- How long does it take to get somewhere
Information you need to collect to assess this:
- You need to know the linear order of a webpage or app.
- You need to know about any hierarchy that is programatically available (e.g. headers)
No way to automatically assess this! Hard to assess well without knowing best tricks for navigation that disabled people use.
---
# What did this page look like?
- This is a title cell
- Navigation 1
- Navigation 2
- Navigation 3
- Navigation 4
- Banner ad
- Right Nav 1
- Right Nav 2
- Right Nav 3- Main content area with lots of text and stories filling the center part of the window.
---
# Original layout of page
(done with tables but imagine it was CSS)
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px;
overflow:hidden;padding:10px 5px;word-break:normal;}
.tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px;
font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;}
.tg .tg-w747{background-color:#dae8fc;text-align:left;vertical-align:top}
.tg .tg-kftd{background-color:#efefef;text-align:left;vertical-align:top}
.tg .tg-ltxa{background-color:#ffccc9;text-align:left;vertical-align:top}
.tg .tg-0lax{text-align:left;vertical-align:top}
</style>
<table class="tg">
<thead>
<tr>
<th class="tg-kftd" colspan="3"><span style="color:#333;background-color:#FFF">Title spanning whole width of table</span></th>
</tr>
</thead>
<tbody>
<tr>
<td class="tg-w747" rowspan="3">Navigation 1<br>Navigation 2<br>Navigation 3<br>Navigation 4</td>
<td class="tg-ltxa">Banner Ad</td>
<td class="tg-w747" rowspan="3">Right Nav 1<br>Right Nav 2<br>Right Nav 3</td>
</tr>
<tr>
<td class="tg-0lax" rowspan="2">Main content area with lots of text and stories <br>filling the center part of the window</td>
</tr>
<tr>
</tr>
</tbody>
</table>
---
# Example: Swipe Order
.left-column40[
]
.righ-column60[
What focus order makes sense for the Facebook newsfeed?
Does this match the actual focus order?
When might you need to *skip* things?
]
---
## What order do you think will be used (1 of 2)
.left-column40[
]
.right-column60[
Use chunks to group meaningful info and reduce number of navigation steps.
- User can double tap to drill down into chunk (e.g. navigate to the “like” button by drilling down into an individual post).
]
???
ink over!
---
## What order do you think will be used (2 of 2)
.left-column40[
]
.right-column40[
]
---
# More Navigation Concepts
Forms and inputs have issues with *order* and *labels*. This is fixed different ways on different platforms, but all major UI dev tools have APIs for accessibility. Make sure you use them *and* testing.
- Web [advice](http://webaim.org/techniques/forms/controls) and [advanced advice](http://webaim.org/techniques/forms/advanced) on this. Look for similar documentation for android/ios.
Tables are not ideal, but *best* when headers are labeled. Again, check the API for your interface dev platform.
---
[//]: # (Outline Slide)
# Learning Goals for Today
Who Is Responsible for Accessibility?
How Screen Readers Work
Building for Accessibility
- Structure impacts navigation order
- **Need to announce things that change**
---
.column[
]
.column[
## Announce UI changes
If you can't see the UI, you have no idea if login succeeded
Requires *programmatically* calling an API to announce the change
]
--
.column[
## Common places this happens
Dialog boxes
Success notifications
Errors
]
---
# Summary of Common Problems
Common Problems To Remember (from [Ross et al, 2017](https://dl.acm.org/doi/10.1145/3132525.3132547) study of 1000s of android apps)
.left-column50[
| |Description |
|--|----------------------|
|<i class="darklight fa fa-times-circle fa-2x"></i> | Missing element label ||
|<i class="darklight fa fa-retweet fa-2x"></i> | Item label ends with type, e.g., “Play Button.” TalkBack automatically announces item type, so information is redundant |
|<i class="darklight fa fa-eye-slash fa-2x"></i> | UI Change not announced |
|<i class="darklight fa fa-server fa-2x"></i> | Navigation lacks hierarchy; or makes no sense |
]
.right-column50[
| |Description |
|--|----------------------|
|<i class="darklight fa fa-search-minus fa-2x"></i> | Item is too small|
|<i class="greylight fa fa-adjust fa-2x"></i> | Low contrast in image or icon |
|<i class="greylight fa fa-quote-left fa-2x"></i> | Low text contrast between foreground and background ||<i class="darklight fa fa-retweet fa-2x"></i> | Item's role identical with alt text|
]
---
# Key Take Home Message
IF you take one thing away from this whole discussion, it should be:
*YOU* decide who is disabled with respect to the technology you create
---
[//]: # (Outline Slide)
# Learning Goals for Today
Who Is Responsible for Accessibility?
How Screen Readers Work
Building for Accessibility
- Structure impacts navigation order
- Need to announce things that change