Best Practices in Accessible Interface Design

# Best Practices in Accessible Interface Design
Using inspection methods and a AT for accessibility auditing

CSE443: Winter 2026; Jennifer Mankoff (Last Edited: 2026-01-04). <a href="/courses/cse443/26wi/slides/best-practices.html">Live View: /slides/best-practices.html</a>

Important Reminder: check zoom & captioning

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

---
## TODOS

[TODO] need to go over this whole deck

[TODO] merge with [2024 versionn](https://courses.cs.washington.edu/courses/cse493e/24au/slides/best-practices.html#26)

[TODO] add descrption of AT Trial assignment

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

---
# Lifecycle of a browser* loading a page

.left-column40[
1. Fetch the page
2. Parse the page
3. Build up an internal representation of the web page
4. Display the page
]
.right-column60[
![:img Screen capture of the UW news front page, 60%,width](img/building/webpage.png)
]
.footnote[*: As seen by Chrome]

---
# Parse and Display the Page

.left-column[
![:img Initial screen for the spot the heron app, 90%,width](img/building/spottheheronscreen.png)

]

.right-column[
1. First line: <!DOCTYPE html>
   -  Ok: need to build an internal representation of the page
2. Line-by-line, go through the HTML
   - If one of the tags links to a cascading style sheet (CSS) file, load and parse it
   - If one of the tags links to Javascript (JS) for behavior, load and parse it
3. FINALLY display the page…
]

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

---
## 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 (first person accounts, research papers, etc). If you use Generative AI, you still need to check and cite relevant references. 
- You must use a screen reader and one other AT, such as:
   - [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

---
class: center, middle, inverse
# Trying this with a Screen Reader

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

---
## Turning on your screen reader

iPhone: Can be done in settings -> accessibility -> voiceover

OSX: Settings -> search for voiceover

---
## (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[
![:img screen reader by Sophia Bai from the Noun Project, 100%, width](img/assessment/screenreader.png)
]
.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

---
## ALT-Tab to safari

- Try it: Read the title; use VO (control-option) to move around
- iPhone users try swiping (swipe up slowly until you hear 3 beeps to switch apps from settings)

---
## As you move around 
- Check ALT text
- Check roles ("navigation"; "button"; etc)
- Check headings
- Try to operate the app (fill in the form)

---
## Try it with a website

[TODO decide which one]

---
## Some things I noticed
- "required fields in blue" (not visible to screen reader user)
- I couldn't complete the form. It didn't tell me where the error was
- form labels read twice on laptop

Other issues
- Missing "skip link" 
- Heading level not consistent with semantics
- Carousel not accessible

[All 18 problems](https://a11y-assessments.pages.oit.duke.edu/accessible-u/issues.html)

---
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: An Accessible 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)

---

## How does it convey this to the screen reader?

The button doesn't talk to the screen reader, it provides information via the UI toolkit to the browser, which the screen reader interacts with.u
- Type (Input, button) (content)
- Name (content)
- Where to place it (layout)
- 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?

---
## WCAG Principals Proper Metadata supports
- 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.

---
# Document Object Model (DOM) (1/3)

.left-column[
![:img Initial screen for the spot the heron app, 90%,width](img/building/spottheheronscreen.png)
]

.right-column[
- This builds a hierarchy of document elements in what we call the **Document Object Model**
- The structure of this depends on our HTML (or the toolkit that generates your HTML)
- The structure of this influences layout

]

---
# Document Object Model (DOM) (2/3)

.left-column[
![:img Initial screen for the spot the heron app, 90%,width](img/building/spottheheronscreen.png)
]

.right-column[
What does this hierarchy look like?

]

---
# Document Object Model (DOM) (3/3)

.left-column[
![:img Initial screen for the spot the heron app, 90%,width](img/building/spottheheronscreen.png)
]

.right-column[
<div class="mermaid">
flowchart TD
    A(Main Window)
    B(Vertical Layout)
    C("Spot the Heron" Label)
    D(Picture of a heron in water with some reeds)
    E(Horizontal Layout: Controls)
    F(Left arrow)
    G(Play)
    H(Right arrow)
    A --> B
    B --> C
    B --> D
    B --> E
    E --> F
</div>

]

---
# Let's compare that to an app

.left-column50[
**Interface Programmers** combine *library elements* (e.g. buttons and labels) according to *toolkit rules* &
constraints of *toolkit architecture* (common to all UI toolkits). Example: let's list all the components of this image:

![:img Picture of a very simple interface showing a ringing bell at
left and an x at right to close the window with the words Google
Calendar reminder Christian and Anind (Jen Mankoff) is starting at
12:30pm. Video call between them, 100%, width](img/building/interface.png)
]
.right-column50[
Discussion (post on [Ed](https://edstem.org/us/courses/90089/discussion//3666535))
- What are the "components" in this image?
- What does the "interactor hierarchy" look like for this image
]

???
discuss with your neighbor
- what to draw; where to draw it
---
# Let's compare that to an app (Answer)

![:img Picture of a very simple interface showing a ringing bell at
left and an x at right to close the window with the words Google
Calendar reminder Christian and Anind (Jen Mankoff) is starting at
12:30pm. Video call between them, 100%, width](img/building/interface.png)
]
.right-column50[
<div class="mermaid">
graph TD
W(Window) --> H[Horizontal layout]
	H --> I1[fa:fa-bell Bell ]
	H --> V[Vertical Layout]
	V --> I2[Title: Google Calendar reminder]
    V --> I3[Text: Christian and Anind --Jen Mankoff-- is starting at 12:30pm. - Video call]
</div>

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

---
# Placment (layout)

What position do we use? What coordinate system do we use?

- An absolute position relative to the whole phone?
- A position relative to the whole app, but doesn't include the OS features (like status bars)?
- A position relative to the direct parent of the button, maybe a window *in* the app

--
Or should we let the toolkit decide what's best?

---
# Where should it go?
.left-column50[

Have to set up the layout first so we can see what we've added

This is a "Layout" problem - all UI toolkits have to support layout.

Layout is complicated because we want layout to handle things like resizing or changing from
portrait to landscape mode well.
]
--
.right-column50[
Specified using a  <br>
component hierarchy (a tree)

<div class="mermaid">
graph TD
W(ConstraintLayout) --> V[Ab  TextView--Hello World!]
	W --> V1[fa:fa-square Button--Next ]

class W darkblue
class V1,V blue
</div>

Android's rendering of the same: ![:img How Android Studio shows the interactor hierarchy with a ConstraintLayout holding a TextView and Button, 50%, width](img/building/android-hierarchy.png)
]

---
# What should it do?

What do we tell the toolkit about the button?

We need to know when the user *interacts* with it
- This is called *Event Handling* Example:

```java
Button button = (Button) findViewById(R.id.button);
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        // display a pop up with some text
        Toast.makeText(getApplicationContext(), "Hello!", Toast.LENGTH_LONG).show();
    }
});
```
---
## 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

---
# Structure of a toolkit

Structure of a Toolkit
- Library of components
- Architecture

Note: these definitions have morphed over time, particularly as things have shifted to cross
platform development.
[Here's](https://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library/19790148#19790148)
a reasonable set of definitions.

???
---
# Some Comparisons

| Android | Web |
| --- | --- |
| Java | HTML/CSS/JS |
| Layouts | CSS Flexbox or Grid |
| Interactor Hierarchy   | Document Object Model (DOM) |
| Components | DIVS  |
| Paint objects on a canvas | CSS |
| `onCreate`   | `window.addEventListener("load", init);` |
| `View.OnClickListener#onClick`   | `domElement.addEventListener("click", callback);` |

---
# Which of these Impacts Accessibility?

| Android                        | Web                                               | Accessibility (eg s)                 |
|--------------------------------|---------------------------------------------------|--------------------------------------|
| Java                           | HTML/CSS/JS                                       | Does the toolkit support access?     |
| Layouts                        | CSS Flexbox or Grid                               | Comprehension/Magnification          |
| Interactor Hierarchy           | Document Object Model (DOM)                       | Navigation                           |
| Components                     | DIVS                                              | Alternative text (toolkit dependent) |
| Paint objects on a canvas      | CSS                                               | Color choices                        |
| `onCreate`                     | `window.addEventListener("load", init);`          | Proper Interaction with access API?  |
| `View.OnClickListener#onClick` | `domElement.addEventListener("click", callback);` | See above                                     |

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