Skip to main content
Link
Menu
Expand
(external link)
Document
Search
Copy
Copied
# Accessibility Technologies and the Access Stack How accessibility technologies communicate with websites and apps CSE443: Winter 2026; Jennifer Mankoff (Last Edited: 2026-01-14).
Live View: /slides/access-stack.html
Important Reminder: check zoom & captioning
---
Outline
Assignment 2: AT Trial
(Slide 6)
Trying a website or app with AT
(Slide 12)
Accessibility Stack
(Slide 19)
Toolkit Layers and Accessibility
(Slide 40)
--- class: center, middle, inverse # Announcements --- ## Released Today: AT Trial
Project groups have been posted on Ed
Due on Monday 1/19
Coming up: Screen Reader Tutorial/Crash Course in class on Friday
--- ## Reminder: Section Tomorrow + AT Around Us Presentations
Section is
virtual
tomorrow– Zoom link is posted on Ed
Please be punctual, ready to present, etc.
Remember that this is
not
a graded presentation– it’s mostly just a share-out for folks to gain awareness of more AT
However, you CAN choose to request Extra Participation Points by ensuring you give an accessible presentation (per the guidelines discussed in class)
--- class: center, middle, inverse # Assignment 2: AT Trial --- ## [AT Trial Assignment](../assignments/technology-review/) The goal of this assignment is to give you experience with using common accessibility technologies to access common technology products. - Select two accessibility technogies (ATs) that are commonly used to *access websites/apps* - Select a technology domain (gaming, visualization, etc) and download the most accessible example you can find in that domain. - Try the ATs on the example - Write a reflection --- ## (Mostly) Work Together - Group work on [plain language](/courses/cse443/26wi/competencies/plain-language/) - Group work on [AT familiarity](/courses/cse443/26wi/competencies/at-familiarity/) - Individual work on [first person accounts]((/courses/cse443/26wi/competencies/first-person/) --- ## New 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 --- ## Handins: AT Familiarity Handin *both ATs* - Information about how each 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. --- ## Questions about assignment? [Assignment Link](../assignments/technology-review.html) --- class: center, middle, inverse # Trying a website or app with AT --- ## 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. ] --- ## 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[  ] .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 --- exclude: true ## Howto
- 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) --- exclude: true ## As you move around - Check ALT text - Check roles ("navigation"; "button"; etc) - Check headings - Try to operate the app (fill in the form) --- exclude: true ## Try it with a website [TODO decide which one] --- exclude: true ## 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) --- ## Switch Control ![:youtube Explanation of how to set up switch control, GQKEE9nI1lk] --- ## 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 # Accessibility Stack --- ## How might access impact interfaces? Web browsing involves - Color - Text (shape and size) - Content (images, words, sounds, animation) - Typing (e.g. input to forms) - Mousing (e.g. clicking on links for navigation) - Comprehension (e.g. reading level) --- ## How might access impact interfaces? Therefore… - Visual impairments - Differences understanding content - Differences hearing - Differences manipulating mouse or keyboard ....and more all affect accessibility --- ## 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 **must provide the right structure and information** to support user tools --- ## Most UIs are not Accessible - Over 60% of Android apps missing at least one button label (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 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 et al, 2019](https://dl.acm.org/doi/pdf/10.1145/3308558.3313605)) --- ## Is this changing? Progress here is slow. - Only about 50% of universities in the US teach accessibility at all ([Shinohara... 2018](https://dl.acm.org/doi/pdf/10.1145/3159450.3159484)). - You all will be among the most well trained soon! - Recent DOJ rule caused UW to hire a team of CSE undergrads to help remediate! --- ## Officially Accessible: WCAG 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)](https://www.w3.org/TR/WCAG21/)** - WCAG is an ongoing project - There is no *official* equivalent for non-web programming,
but WCAG can easily be applied to apps as well - Lots of ways to learn WCAG
(e.g. this [certificate program](https://de.torontomu.ca/wa/); this [textbook](https://pressbooks.library.torontomu.ca/pwaa/); and [WebAIM](https://webaim.org)) ??? Most comprehensive and up to date: 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 accessibility technologies (ATs) 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) --- ## What is the problem? - Mostly, it's frontend developers - And content providers --- ## 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) --- ## Let's look under the hood 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) --- ## Then a bunch of other things get involved .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[  ] .footnote[*: As seen by Chrome] --- ## Parse and Display the Page .left-column[  ] .right-column[ 1. First line: - 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… ] --- ## Building for Accessibility
graph LR SR[fa:fa-volume-up
Screenreader
]:::bluelarge -->|Asks for next object in DOM| API(fa:fa-codepen
Accessibility API
):::bluelarge API -->|Passes along request| ATK[
Toolkit
]:::bluelarge ATK -->|Checks Details| App[fa:fa-mobile
App
]:::bluelarge App -->|Name: Foo| ATK ATK -->|Name, Role: Button| API API -->|Name, Role| SR
- 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 | --- ## 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);] | --- # Impacts on 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 --- class: center, middle, inverse # Toolkit Layers and Accessibility --- ## Accessibility in content | Content | Structure | Style | Behavior | | :--: | :--: | :--: | :--: | || | Words and Images | HTML | CSS | JavaScript | --- ## Understandable content has metadata - HTML tag types are metadata - Title `
` (which nests inside your ``) - Headings (`H1`-`H6`) - Paragraphs `
` - Ordered or unordered lists: `
`, `
`, with list elements `
` - Horizontal rules `
` - Strong `
` which defaults to a bold style and emphasis `
` which defaults to italicized in most browsers. ??? There are 100s of possible HTML tags! See [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTML/Element)! --- ## Semantic content - HTML tag types are metadata - Some tags add semantic context - `
`: The header or banner that displays the title of the page - `
`: The bulk of the content of the page - ``: The footer is optional but you can put contact info and copyright date in there. --- ## Metadata content - HTML tag types are metadata - Some tags add semantic context - Some tags need additional information, added to a tag with attributes - Links to other pages `
` - Links to images `
` --- ## Documentation content - HTML tag types are metadata - Some tags add semantic context - Some tags need additional information, added to a tag with attributes - Some tags (comments) are important for documentation `` --- ## 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 content ``
Send
`` 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? --- ## 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. --- ## 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 | Content | Structure | Style | Behavior | | :--: | :--: | :--: | :--: | ||| | Words and Images | HTML | CSS | JavaScript | --- ## 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? --- ## Accessibility in Style | Content | Structure | Style | Behavior | | :--: | :--: | :--: | :--: | |||| | Words and Images | HTML | CSS | JavaScript | --- ## 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 for the styles to work `
` - 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/) --- ## Accessibility in Behavior | Content | Structure | Style | Behavior | | :--: | :--: | :--: | :--: | ||||| | Words and Images | HTML | CSS | JavaScript | --- ## What should it do? - What do we tell the toolkit about the button? -- - We need to know when the user *interacts* with it (i.e. *Event Handling*) ```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. --- ## Common errors not in WCAG Some common errors aren't in guidelines because they are either tool specific or straight up UX errors: -
TextView has a content description (interferes with screen reader reading the the text field) -
Overlapping clickable items -
URL in link invalid