Best Practices in Accessible Interface Design

# Best Practices in Accessible Interface Design
## CSE513: Fall 2025
Jennifer Mankoff
2025-10-12
       
Important Reminder: check zoom & captioning

<a href="/courses/cse513/25au/slides/best-practices.html">Live View: /slides/best-practices.html</a><br>
<a href="/courses/cse513/25au/slides/best-practices.html"><img src="https://api.qrserver.com/v1/create-qr-code/?data=/slides/best-practices.html&size=100x100" alt="QR for /courses/cse513/25au/slides/best-practices.html" title="" /></a>

---
class: center, middle, inverse
# Announcements

---
## Jen's situation

- Major family emergency
- Out since last Thursday
- Trying to return to asynch work this week

---
## Upcoming things for class

- HW3 starts this week. It's a 2 week homework (but overlaps ASSETS for some)
- Proposals due 11/3. To facilitate project team formation, please post your preliminary ideas and reactions on Ed by 10/25.
   - We'll reserve class time for groups to talk for 10 minutes on 10/27. 
   - We encourage you to use 10/29 class time to meet and do further planning
   - You'll present to class on 11/3

---
class: center, middle, inverse
# Introduction

---
## Most WWW and Apps not Accessible

- Over 60% of Android apps missing at least one label on a clickable element (out of 5721 apps tested) ([Ross, 2020](https://dl.acm.org/doi/pdf/10.1145/3348797))
- Over 80% of fortune 500 websites not accessible ([Loiacono, 2009](https://dl.acm.org/doi/pdf/10.1145/1562164.1562197))
- University websites are also partly to mostly inaccessible ([Campoverde-Molina, 2021](https://link.springer.com/content/pdf/10.1007/s10209-021-00825-z.pdf))
- Less than 1% of Twitter images had ALT text in 2019 ([Gleason, 2019](https://dl.acm.org/doi/pdf/10.1145/3308558.3313605))
- Only about 50% of universities in the US teach accessibility at all ([Shinohara, 2018](https://dl.acm.org/doi/pdf/10.1145/3159450.3159484)).

???
More study is needed, but overall, progress here is slow.

This last point relates to our discussion of software engineers and accessibility in a week -- we are simply not training people to do this (or AI!)

---
## What is the goal?

All users interact with the *same* website or app as anyone else

Users may use browser features or a specialized accessibility tool to customize their experience

--
**This is Key**

Website or app designer provides the right structure and information to support this

---
## Where does accessibility show up? (1/4)

---
## Where does accessibility show up? (2/4)

---
## Where does accessibility show up? (3/4)

---
## Where does accessibility show up? (4/4)

- 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.

???
As an example, we'll focus on screen readers

Screen readers get underlying information about controls from operating systems.

---
## Different types of interface toolkits all have similar libraries

| Does What? | Android | Web |
|--- | --- | --- |
| Content| Java | HTML/CSS/JS |
| Style | Layout | CSS |
| Structure | Interactor Hierarchy   | Document Object Model (DOM) |
| Content |  Components | DIVS  |
| Style |  Paint objects on a canvas | CSS |
| Behavior | Event Handling   | Event Handling/JS |

---
## Testing For Accessibility?

Automated Tools

Design Guidelines (i.e. know them and apply them heuristically)

**Manual Testing** (Try it yourself using accessibility technologies or simulators such as [aDesigner](https://www.eclipse.org/actf/downloads/tools/aDesigner/))

User Testing

---
# Manual Assessment Warning

Simulation tends to cause people to underestimate what is possible

Helps to learn *how* to use things but never assume you are proficient

We'll touch on screen readers, magnifiers & so on today

???
Remind them about drone video

Don't fall into the trap of assuming that your ineptitude is the standard disability experience

---
## Competency: AT familiarity

- Information about how the AT works, users, and strengths and weaknesses of the AT. 
- Information about what disabilities can benefit from it. For example, screen readers are not just used by blind people. 
- Any sources you used to answer these questions (first person accounts, research papers, etc). If you use Generative AI, you still need to check and cite relevant references. 
- Testing is a great place to explore these. Example ATs you can explore
   - [Switch Control](https://www.youtube.com/watch?v=GQKEE9nI1lk) 
   - [Magnification](https://www.youtube.com/watch?embeds_referring_euri=http%3A%2F%2Flocalhost%3A4000%2F&source_ve_path=Mjg2NjQsMTY0NTAz&v=PMihdIZUh7Y&feature=youtu.be)
   - Change coloring in your browser (e.g. [Dark mode](https://www.youtube.com/watch?v=lDJlzyEsibU))
   -  ...

???
- Switch users, turn this on, on your phone

---
exclude: true

## Switch Control

![:youtube Explanation of how to set up switch control, GQKEE9nI1lk]

---
exclude: true

## Magnification

![:youtube How to magnify your windows desktop, PMihdIZUh7Y?feature=shared&t=81]

???
- Magnification users, turn this on, on your phone

---
exclude: true

## Browser Settings

- Change font size 
- Change color contrast
- Change from light to dark mode

---
## Screen Readers

.left-column-half[
Different types of screen readers.
- JAWS for Windows
- Nonvisual Desktop Access
- VoiceOver
- TalkBack
- ChromeVox

]
.right-column-half[
![:img JAWS logo. A blue shark; with talking rings over blue text that reads JAWS, 30%, width](img/assessment/JAWS_logo.png) ![:img NVAccess logo. geometric shapes intermix in orange blues and purple. text reads; NVAccess empowering lives through non-visual access to technology, 50%, width](img/assessment/NVDA_logo.png)

*Where can you find one?*
Different devices used to interact with screen readers.
]

---
class: center, middle, inverse
# Learning Goals

---
## Lots of learning goals today

- Introducing Accessibility Standards
- Manual Accessibility Testing
  - We will focus on screen readers 
  - And understanding structure in interactive apps
  - And how this impacts user agents (such as screen readers)
- Building for Accessibility
- Assignment
- [if time] Get comfortable using existing freely available accessibility technology to manually support assessment

---
class: center, middle, inverse
# Building for Accessibility

---
## WCAG is the gold standard

Most comprehensive and up to date:  Web Accessibility Initiative ([WAI](http://www.w3.org/wai/)), a service of the World Wide Web Consortium (W3C) 
- Makes recommendations for Web authors, browsers and servers: **Web Content Accessibility Guidelines (WCAG)**
- WCAG is an ongoing project 
- There is no *official* equivalent for non-web programming, <BR> but WCAG can easily be applied to apps as well 
- Lots of ways to learn WCAG <BR> (e.g. this [certificate program](https://de.torontomu.ca/wa/); this [textbook](https://pressbooks.library.torontomu.ca/pwaa/); and [WebAIM](https://webaim.org))

???
We could spend a whole quarter on this... but we're going to limit it to one or two weeks

"live" (regularly being worked on and updated, with input from the disability community).

---
## The [POUR](https://webaim.org/articles/pour/) standard

- Perceivable: Web content is made available to the senses - sight, hearing, and/or touch
- Operable: Interface forms, controls, and navigation are operable
- Understandable: Information and the operation of user interface must be understandable.
- Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies

Note: There is a 5th thing, Conformance, that you "you meet or satisfy the 'requirements' of the standard."

???
This is appropriate for *all* disabilities -- don't think access is only an issue for blind and low vision (BLV) people

Obviously there is some overlap between these, and they build on each other

---
## Three levels of compliance

*Some* users with disabilities can access and use web content (A)

*Removal of significant barriers* overall to accessing content (AA)

*Enhancements to web accessibility* for more users with disabilities (AAA)

Most apps and websites today only meet  *part* of (A) level compliance!

---
exclude: true

## Testing Accessibility? Automated tools

- [Review of many options](https://medium.com/@OPTASY.com/what-are-some-of-the-best-web-accessibility-testing-tools-to-evaluate-your-website-with-69def25a386)
- Web: WebAIM's [WAVE](https://wave.webaim.org/);
- Browser Extensions ([Comparison Article](https://medium.com/@OPTASY.com/what-are-some-of-the-best-web-accessibility-testing-tools-to-evaluate-your-website-with-69def25a386)): [WAVE](https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh?hl=en-US); [Axe](https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US); [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/); [Siteimprove](https://chrome.google.com/webstore/detail/siteimprove-accessibility/efcfolpjihicnikpmhnmphjhhpiclljc/related);  & other browser extensions
 - Phone apps: [Google Accessibility Scanner](https://support.google.com/accessibility/android/answer/6376570?hl=en&ref_topic=6376582) and [iOS.](https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTestingApps.html)

---
## Example: Adding a button

When you hear the word "button" in the context of a graphical user
interface (GUI), what do you think of?

---
## What should it do?

- content?
- structure?
- style?
- behavior?

[Making Accessible Buttons](https://jessijokes.medium.com/one-button-to-rule-them-all-465e294cba82)

---

## What should it do? (my answers)

What do we tell the toolkit about the button?
- That it is a button (content)
- What it says (content)
- Where to place it (structure)
- How it looks (style)
- How it should react to user input and from which device? (behavior)

---
## Accessibility in content

---
## Understandable content has metadata

- There are 100s of possible HTML tags! See [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)!
- Some simple tags
  - Title `<title></title>` (which nests inside your `<head></head>`)
  - Headings (`H1`-`H6`)
  - Paragraphs `<p>`
  - Ordered or unordered lists: `<ol></ol>`, `<ul></ul>`, with list elements `<li></li>`
  - Horizontal rules `<hr />`
  - Strong `<strong></strong>` which defaults to a bold style and emphasis `<em></em>` which defaults to italicized in most browsers.

---
## Semantic content

- There are 100s of tags! See [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)!
- Some simple tags
- Some tags add semantic context
  - `<header></header>`: The header or banner that displays the title of the page
  - `<main></main>`: The bulk of the content of the page
  - `<footer></footer>`: The footer is optional but you can put contact info and copyright date in there.

---
## Metadata content

- There are 100s of tags! See [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)!
- Some simple tags
- Some tags add semantic context
- Some tags need additional information, added to a tag with attributes
  - Links to other pages `<a href="filename"></a>`
  - Links to images `<img src="img.jpg" alt="Description!"/>`

---
## Documentation content

- There are 100s of tags! See [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)!
- Some simple tags
- Some tags add semantic context
- Some tags need additional information, added to a tag with attributes
- Some tags (comments) are important for documentation ``

---
## Button content

``<button id="send-feedback-btn" aria-label="Send Feedback">Send</button>``
 
Note: By using the ``button`` tag, we get free support for proper representation of role and state

Which Perceivable/Operable/Understandable/Robust principals do each of these demonstrate?

---
## My answer (button content)
- Aria label ([Perceivable non-text information](https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html))
- Generally valuable ([G115](https://www.w3.org/WAI/WCAG21/Techniques/general/G115)): Using semantic markup such as ``<button>``

---
exclude: true

## Interactive Component ALT text

- What is a good name for a "Like" Button?

- Enable the user to understand the name of the control they have navigated to, what type of control it is, what value it has, what state it has.

---
exclude: true
## Proper ALT text

Screen reader will read out name, role, and state. Don't repeat these.

Good alt text: Name ("Like")

API knows: Role ("Button")

API knows: State ("Not selected")

---
## Accessibility in structure

---
## Button Structure

Minimum needed for screen reader access 
- Where it is (structure)
- Can I get to it (location)

Makes the interface "Operable" -- [WCAG guideline 2.4 (Navigable)](https://www.w3.org/WAI/WCAG21/Understanding/navigable.html)

???
Naturally exists in the interactor hierarchy/DOM, but is it in an intuitive place for navigation?

---
## 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 programmatically available (e.g. headers)

No way to automatically assess this! Hard to assess well without knowing best tricks for navigation that disabled people use.

---
## A page with layout

.left-column60[
(table 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>
<div class="table-wrapper"><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></div>
]
.right-column40[
What focus order makes sense for the Facebook newsfeed?

Does this match the actual focus order?

When might you need to skip things?
]
---
## Linear Order with no CSS

Depends on how the page was designed. One possibility

- Title
- Right Nav 1
- Right Nav 2
- Right Nav 3
- Navigation 1
- ...
- Navigation 4
- Banner ad
- Main content area

---
## Swipe order? (bad)

.left-column60[
| Cell         | Nefarious order |
|--------------|-----------------|
| Title        | 1               |
| Right Nav 1  | 8               |
| Right Nav 2  | 9               |
| Right Nav 3  | 10              |
| Banner ad    | 3               |
| Navigation 1 | 4               |
| Navigation 2 | 5               |
| Navigation 3 | 6               |
| Navigation 4 | 7               |
| Content      | 11              |

]
.right-column40[
<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>
<div class="table-wrapper"><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">Nav 1<br>Nav 2<br>Nav 3<br>Nav 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 filling the center part of the window</td>
  </tr>
  <tr>
  </tr>
</tbody>
</table></div>
]

---
## Swipe order? (better)

.left-column60[
| Cell         | Well designed order |
|--------------|---------------------|
| Title        | 1                   |
| [skip cell]  | 2                   |
| Right Nav 1  | 3a                  |
| Right Nav 2  | 3b                  |
| Right Nav 3  | 3c                  |
| Banner ad    | 3e                  |
| Navigation 1 | 3a                  |
| Navigation 2 | 3b                  |
| Navigation 3 | 3c                  |
| Navigation 4 | 3d                  |
| Content      | 3                   |

]

---
## Swipe order? (best)

.left-column60[
| Cell        | Chunked order |
|-------------|---------------------|
| Title       | 1                   |
| [skip cell] | 2                   |
| Nav Area    | 3                   |
| Right Nav | 3a |
| Right Nav 1  | 3a.1                  |
| Right Nav 2  | 3a.2                  |
| Right Nav 3  | 3a.3                  |
| Left Nav | 3b |
| Navigation 1 | 3b.1                  |
| Navigation 2 | 3b.2                  |
| Navigation 3 | 3b.3                  |
| Navigation 4 | 3b.4                  |
| Banner ad    | 3c                  |
| Content      | 4                   |

]
???
- User can double tap to drill down into chunk (e.g. navigate to the “like” button by drilling down into an individual post).

---
## 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* test them.
- 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.

---
## Accessibility in Style

---
## Cascading Style Sheets (CSS)

- Allows us to change the look and feel of the content on the page
- Style is separated into a .css file
  - Makes styling multiple pages easier
  - Allows changing multiple pages easier
- Style sheets must be linked to an html page in the<head> for the styles to work
     `<link href=“style.css” rel=“stylesheet” />`
- Great example is [CSS Zen Garden](http://www.csszengarden.com/)

---
## Styling Buttons for Accessibility
- Minimum size: 7x7mm for touch screens (but ideally should resize on larger screens)
- Padding around the button
- Color contrast
- Visually indicate focus (example)
``#send-feedback-btn:focus {outline: 2px solid #0000ff;}
``

Small group discussion: Which Perceivable/Operable/Understandable/Robust principals do each of these demonstrate? Check the table of contents for [WCAG 2.1](https://www.w3.org/TR/WCAG21/)

---
## My POUR analysis
- Minimum size = Operable
- Padding around button = Operable
- Focus Visible = Operable
- Contrast = Perceivable

---
## Accessibility in Behavior

---
## Button Behavior

Use a library element or ensure that events are properly announced
  - State changes
  - Invocation

---
## Other 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 aren't in guidelines because they are either tool specific or straight up UX errors:
 - <i class="darklight fa fa-strikethrough fa-2x"></i>  TextView has a content description (interferes with  screen reader reading the 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 invalid

---
## 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

---
class: center, middle, inverse
# Auditing for Accessibility

---
## Audit "Problem Reports"
- Name/Brief Description - Brief and Specific (Unique)
- Testing Method - What tools found this problem (screen reader? manual? etc)
- Evidence - WCAG guideline violated; screenshot with evidence of the violation.
- Explanation - Explain the issue and  possible causes.
- Severity & Justification (next slide)
- Possible solution

---
## Severity
Severity - Rank severity 1-4
  1. Cosmetic
  2. Minor: Low Priority
  3. Major: High Priority
  4. Catastrophe

---
## Severity Justification 
Justify your ranking in terms of frequency, impact and persistence.
  - Frequency - Is the problem common or rare?
  - Impact - Is it hard or easy to overcome this?
  - Persistence - Is there a way to work around this problem?
  - Possible Solution - Explain a potential solution to improving the accessibility.

---
## Example

![:img A picture of a simple calculator showing the number 42. The background is black, the buttons are light grey and grey and yellow, and the text on them is in white](img/best-practices/calculator.png)