Accessibility on the web

history, screenreaders usage and good practices in code

women++ presentation

Wednesday, Sep 8

Nothing AG, Bern

nothing.ch/accessibility 🔗

Live, accessible slides broadcast

See event description 🔗
Please use only as additional aid
Shared screen is main reference
- Switch between applications
- Play videos

➡️ Intro
📚 History
🛠 Good practices in code (part 1)
🖥 Screen readers
🛠 Good practices in code (part 2)
⬅️ Outro

Table of content

Hello everybody! 👋🏼

Joanna Salathé
Software engineer graduated from EPFL
Web Developer (Frontend) ~ 4 years
Very interested in (gender) diversity
Inclusion should be about all individuals
Use technology to make a positive impact (e.g. with accessibility)

Nothing AG

Peer-to-peer (P2P)
Digital agency, Venture lab
Bern, Switzerland

Nothing AG

www.nothing.ch 🔗

www.peerdom.org 🔗

Join us! 🔗

Goal
Become a well-known "accessibility-first" web
company in (and outside) Switzerland

Our accessibility support

Design reviews
Semantic HTML prototyping
Visual and functional prototyping
Reviews & optimisations of existing project
Presentations and workshops
Hands-on work on your product
Written & video documentation

Reach out: josua@nothing.ch ✉️

nothing.ch/accessibility 🔗

20+ years ago

(aka. "The Dark Ages")

1808: First typewriter

Invented by Pellegrino Turri (incl. ink paper)
For blind friend Countess Carolina Fantoni da Fivizzano
- Could write, but not read
- Proofreading impossible

Countess Carolina sitting in front of typewriter

Thinking outside the box

1824: Braille

Communication still tedious!

Tactile writing system
Invented by Louis Braille (at age of 15)
- Could read, but not write

Until invention of braille typewriters
Not readable by most other people

Modern times

Everything's better now (?)

Until 2010: Early digital accessibility

Stable working screen readers and OS (desktop)
- Scan papers (OCR)
- Navigate the web
- Read and write emails

(Good) Simple and traditional services
- Not so many ("Web 1.0") ➡ accessible
(Bad) Sophisticated and expensive
hardware/software

Today: Opportunities...

How important is to YOU...
- The Internet?
- Your smartphone?
Control virtual and physical world
- "Internet of things" (IoT)
Mobile screen readers
- Free & easy

Endless possibilities (?)

...vs. obstacles!

Modern apps and websites are "fancy"
- Visually oriented
- Complex

A lot of basic requirements are prone to be "forgotten"
- Valid (semantic) HTML
- Keyboard-only navigation
- Text alternatives for images
- Good color contrast

Most harmful situation

Disabled people are often excluded from the digital world

Although, they are the ones that are by far the most...
- Dependent
- Profiting

Services are transferred from the physical to the virtual world
- Categorically excluding more people
- Problem just becomming bigger and bigger

Two-class society in the digital world?

Default users vs. people of disability
Fanciness often goes against usability & accessibility
Technically, everything would be ready

aesthetics can be 100% accessible!

Public pressure increasing

National and international laws adapting

Europe
- (2006) Convention of the United Nations on the rights of persons with disabilities
  - (since 2014) Ratified by Switzerland
  - (future) Even private sector held responsible
USA
- Waves of lawsuits
  - Better to raise awareness than negatively punishing

More awareness due to the current pandemic

Possibilities

For today and tomorrow

So much is possible!

Daniele Corciulo (accessibility expert, 1.5% eyesight)
- Former employee of foundation «Access for all»
- Now working at Fachstelle Studium und Behinderung at University of Zürich
Let's Play "Last of us 2" (blind) 🔗

Song "Take my hand" 🔗

Daniele is enabled to...

Use public transport
- Electronic time table (Braille
  handles, guidelines for white stick)
Read paper mail
- Scan, then OCR and text-to-speech
Identify objects
- Scan bar codes
Operate the coffee machine
- Smartphone app (through
  Bluetooth) and screen reader

Forms of disability

Visual (up to blindness)
Hearing (up to deafness)
Motor (e.g. a broken arm)
Cognitive and neurological (e.g. attention deficit)
Age related (we will all have more difficulties)

Unlocking human potential

Creating accessible products means...
- Equality, regardless of (physical) differences
It's not about creating "social welfare state"
It's about including & unlocking human potential
- We, as society, can benefit from this!
- Disabled people think outside the box!
Remember the typewriter?
- Would we have smartphones today?

Human potential is the only limitless resource we have on this earth.

(Carly Fiorina)

A question

of trust

What do you trust more?

<a href="…">
  Click me!
</a>

<span onclick="location.href='…'">
  Click me!
</span>

Why?

Valid vs "Traditional" HTML

<a> : The Anchor element 🔗

<span> : The generic inline container 🔗

The <a> HTML element [...] creates a hyperlink to web pages, [...] or anything else a URL can address

The <span> HTML element [...] is a generic inline container for phrasing content, which does not inherently represent anything

It should be used only when no other semantic element is appropriate

Benefits of traditional HTML

<a href="…">
  Click me!
</a>

<span onclick="location.href='…'">
  Click me!
</span>

Behaviour for free
- Go to address on click
- Keyboard focusability
Styles for free
- Underline
- Focus, hover, active states

Compatibility
- Backwards and forwards
- Better performance (works without Javascript)

Sure, we can do "enhancements"

<a href="…">
  Click me!
</a>

<span onclick="location.href='…'"
      class="link"
      tabindex="0"
      role="link">
  Click me!
</span>

Apply custom...
- aesthetics
- behaviour
- semantics

But how will it perform?

Still: it's not really a link!
- No complete keyboard handling
- Can't open context menu
- Can't bookmark
- Possibly many more things

Codepen 🔗

Traditional HTML beats quirky custom solutions

Much functionality "for free"
Robust
Performant

<a href="…">
  Click me!
</a>

<span onclick="location.href='…'"
      class="link"
      tabindex="0"
      role="link">
  Click me!
</span>

⇩

But why

would anyone do this?!

Reason I: Ignorance

The button vs link case

<a> : The Anchor element 🔗

The <a> HTML element [...] creates a hyperlink to web pages, [...] or anything else a URL can address

<button> : The Button element 🔗

The <button> HTML element represents a clickable button, used to submit forms or [...] for standard button functionality

Reason I: Ignorance

But confusion happens when....

MDN: Styling links as buttons 🔗

Reason I: Ignorance

But confusion happens when....

MDN: Styling links as buttons 🔗

Medium: But sometimes links look like buttons (and buttons look like links) 🔗

<ul class="references-guides " role="menu">
 <li role="none">
  <a tabindex="-1" href="/en-US/docs/Learn" role="menuitem">
   Learn web development
  </a>
 </li>
 ...
</ul>

Reason I: Ignorance

<button onclick="location.href='…'">
  Wrong!
</button>

Please stop doing this!

Even if visually sometimes buttons and links styling are exchanged (and visual users are used to it), you should always remain semantically correct in HTML !

<a> or form submits ➡ trigger a navigation change

<button> or form elements ➡ trigger a UI state change

Reason II: HTML can't be styled

<select>
  <option id="cat">Cat</option>
  <option id="dog">Dog</option>
</select>

<style><!-- Won't have an effect -->
  select { font-weight: bold; }

  #cat { background-color: blue; }
  #dog { background-color: red; }
</style>

In earlier days, many HTML elements offered limited CSS
- Some still can't be styled

Reason II: HTML can't be styled

<select>
  <option id="cat">Cat</option>
  <option id="dog">Dog</option>
</select>

<style><!-- Won't have an effect -->
  select { font-weight: bold; }

  #cat { background-color: blue; }
  #dog { background-color: red; }
</style>

In earlier days, many HTML elements offered limited CSS
- Some still can't be styled

Instead, use role-attributes
- role="listbox" for <select>
- role="option" for <option>

<div role="listbox">
  <div role="option" id="cat">Cat</div>
  <div role="option" id="dog">Dog</div>
</div>

<style>
  [role=listbox] { font-weight: bold; }

  #cat { background-color: blue; }
  #dog { background-color: red; }
</style>

Reason III: HTML missing

Quite a few well established usage patterns without HTML equivalent.

Requires to tinker own custom solution.

<ul role="tablist">
  <li role="tab">
    <a href="#section1" role="presentation"
        id="tab1" aria-selected="true">
      Tab 1
    </a>
  </li>
</ul>

<section id="section1" role="tabpanel"
    tabindex="-1" aria-labelledby="tab1">
  Content 1
</section>

<!-- No such thing -->
<tablist>
  <tab id="tab1">Tab 1</tab>
  <!-- And more tabs -->

  <content for="tab1">
    Content 1
  </content>
  <!-- More content -->
</tablist>

ARIA specification

Accessible Rich Internet Applications standard
Version 1.0 🔗 released in 2014 by W3C 🔗

Offers attributes to enrich valid HTML with semantics
But: they don't add functionality!

Still a lot of JavaScript to add:
- Manage visibility/style (dynamically)
- Provide keyboard functionality
- Update semantic state
  - aria-selected="true"
Quickly becomes complex

<div role="listbox">
  <div role="option" id="cat">Cat</div>
  <div role="option" id="dog">Dog</div>
</div>

<style>
  [role=listbox] { font-weight: bold; }

  #cat { background-color: blue; }
  #dog { background-color: red; }
</style>

ARIA example

Collapsible Dropdown Listbox Example: w3c.github.io/aria-practices 🔗
- ~150 lines of CSS
- ~900 lines of JavaScript!
Support varies drastically among browser / screen reader combos
ARIA offer limited:
- "listbox" or "tablist" available
- "datepicker" and others missing
- You will quickly reach the point where there is no official recipe
So: what to do then?

First rule of ARIA use

" If you can use a native HTML element (or attribute) with the semantics and behavior you require, then do so. Do not instead re-purpose an element and add an ARIA role, state or property to make it accessible. "

Source: w3.org/TR/using-aria/#rule1🔗

There (nearly) always exists a traditional element, even when not obvious at first sight!

Fog of War

Try to play Pacman...

...but with Fog of War!

?

Screen readers are like Pacman

but with fog of war!

They start at the top of the page
They allow to navigate through DOM
- Sequentially conveying one object after the other

Vision is two-dimensional
- Perception of surface
- Overview of web page within 1sec
Audio (speech) is one-dimensional
- Try to listen to people in parallel

Screen readers are linear (1D)

Screen readers are slow (is it?)

Reading through full website takes time (top to bottom)
- Usually specific interest (e.g. article or product)
Speech rate can be increased
- Up to 1 mio. percent
Blind users rely on other ways to navigate
- Heading outline
- List of all links / form controls
- Etc.

Screen readers:

Why they are important

Importance of semantics

Philosophy & Linguistics: The study of meanings
UI / Web Development, it refers to:
- The meaning of UI elements
- The overall meaning of the content structure
For example
- "This is a heading"
- "This is a heading of level 2"
- "This is a text input"
Screen readers evaluate this info
- They convey it to user (through audio)
- This allows meaningful interaction with elements

Bad vs. good semantics

Codepen 🔗

Bad vs. good semantics

Codepen 🔗

This is very similar to Word's styles!

d

Litmus tests

Screen reader tests are considered "litmus tests" in the development of accessible user interfaces

"If you say that something is a litmus test of something, you mean that it is an effective and definite way of proving it or measuring it." (CollinsDictionary.com)

If a website can be read and operated by a screen reader, it can be considered pretty accessible (regarding non-visual aspects)
- Use them to validate the a11y level of your website!

BUT keep in mind that for other form of disability other requirements must be respected (e.g captions for videos)

NVDA (desktop SR)

Most used screen reader: NVDA (Non-Visual
Desktop Access)
Native Windows application
Open Source: github.com/nvaccess/nvda 🔗

Free to use
Friendly & Responsive community

Especially suited for testing of websites
- Adheres to standards
- Non-intrusive and fast
- Visual cursor & Speech Viewer!

Mobile screen readers

VoiceOver (iOS)/TalkBack (Android)
Integrated by default (wide distribution)
Good accessibility support
Much simpler to use than desktop

3 commandments

of screen readers

I: Reveal the Meaning

Screen readers read and convey semantic information only.

<a href="...">Click me!</a>
<p>Some text here.</p>
<h2>A second level heading</h2>
<input type="text">

<!-- ?? -->
<span onclick="location.href='…'">
  Click me!
</span>

They are not interested in visual stylings.

.heading {
  font-weight: bold;
  font-size: 28px; }

.link {
  text-decoration: underline; }

To be conveyed through audio, an element's meaning must be obvious.

II: Instruct the ways of Interaction

If an element is interactive, it must be obvious how to interact with it.

Traditional HTML is self-explanatory.

Custom solutions need manual explaining.

<label for="hobby">
  Favourite Hobby
</label>

<select id="hobby">
  <!-- List of <option>
       elements -->
</select>

<!-- A JavaScript autocomplete -->
<label for="hobby">Favourite Hobby</label>
<input id="hobby" aria-describedby="description">

<!-- Custom list of suggestions -->

<p id="description">
  This is an autocomplete. Enter characters
  to display suggestions, then select one.
</p>

III: Feedback needs to be Concise!

If an element is interacted with, it must provide clear and immediate information on what's the result of the interaction.

<!-- A JavaScript autocomplete -->
<label for="hobby">Favourite Hobby</label>
<input id="hobby" aria-expanded="false">

<!-- List of (initially hidden) suggestions -->

<script>
  // On focus, toggle aria-expanded="true"
  // (and show list of suggestions).
</script>

5min break

Nothing AG, Bern

nothing.ch/accessibility 🔗

Take it to the test:

a closer look at custom dropdown

Google autocomplete

URL: google.com 🔗
role attributes

<ul role="listbox">
  <li role="presentation">
    <div role="option">1st option</div>
  </li>
  <li role="presentation">
    <div role="option">2nd option</div>
  </li>
</ul>

Google autocomplete

URL: google.com 🔗
role attributes
Mediocre screen reader accessibility
- Announces itself as searchable combo box 👍
- Does not announce availability of options 👎
- Announces selected option 👍

<ul role="listbox">
  <li role="presentation">
    <div role="option">1st option</div>
  </li>
  <li role="presentation">
    <div role="option">2nd option</div>
  </li>
</ul>

Amazon autocomplete

<div>
  <div>
    <span>1st option</span>
  </div>
  <div>
    <span>2nd option</span>
  </div>
</div>

URL: amazon.com 🔗
<div> and <span>
Bad screen reader accessibility
- Announces itself as bare text search 👎
- Does not announce availability of options 👎
- Announces selected option 👍

Interim conclusion

Both need a dropdown
Dropdown needs fancy styling
- <select> not an option
Google uses ARIA
Amazon uses <div> and <span>
Lots of JavaScript, mediocre to bad accessibility
Couldn't this be done better?

No traditional HTML element available...?

Hmmm...

A <select> offers predefined list of options
One of which can be chosen
What other HTML element allows for this?

Come on!

Radio buttons!

100% customisable
- <label> elements can be styled
- <input> can be visually hidden (moved off-screen)
No JavaScript needed
100% accessible

A listbox

of radio buttons!

A11y Dev Guide (ADG)

accessibility-developer-guide.com 🔗
Comprehensive resource
- Tangible and technical
- Easy to understand
- Code examples
By developers, for developers
Open Source
- github.com/Access4all/adg 🔗

Screenshot of Accessibility Developer Guide

ADG autosuggest

ADG URL: examples/widgets/autosuggest/ 🔗
Radio buttons

<input type="radio" name="hobbies" id="dancing">
<label for="dancing">Dancing</label>

<input type="radio" name="hobbies" id="gardening">
<label for="gardening">Gardening</label>

ADG autosuggest

ADG URL: examples/widgets/autosuggest/ 🔗
Radio buttons
Very good screen reader accessibility
- Announces itself appropriately 👍
- Announces availability of options 👍
- Announces selected option + total of options 👍

<input type="radio" name="hobbies" id="dancing">
<label for="dancing">Dancing</label>

<input type="radio" name="hobbies" id="gardening">
<label for="gardening">Gardening</label>

Only tiny bit of JavaScript!

Verdict

Very accessible
~60 lines of CSS
~230 lines of JavaScript
- Including filter functionality

Unexpected usages of form controls

Datepicker (radio buttons)
- ADG - examples/widgets/datepicker/ 🔗
Tablist (radio buttons)
- ADG - examples/widgets/tablists/ 🔗
Carousel (radio buttons)
- ADG - examples/widgets/carousel/ 🔗
Accordion: single (radios) / multiple (checks)
- ADG - examples/widgets/accordion/ 🔗

Let's recap

Form controls are powerful

They can handle many simple usage patterns
- They handle much more than basic user input
- Can be combined for complex ones
They are:
- Simple and compatible
- Robust and performant
- Innately accessible
They can be styled as wished

What do you trust?

<a href="…">
  Click me!
</a>

<span onclick="location.href='…'"
      class="link"
      tabindex="0"
      role="link">
  Click me!
</span>

Remember next time

When you're tempted to glue together some random <div> / <span> elements with JavaScript handlers

We are keen to support you!

Design reviews
Semantic HTML prototyping
Visual and functional prototyping
Review & optimise existing project
Presentations and workshops

Book a virtual coffee 🔗 ☕

Five code improvements you can apply today to make your website more accessible 🔗

Reach out: josua@nothing.ch ✉️

nothing.ch/accessibility 🔗

checklist 🔗

Thank you!

Reach out: joanna@nothing.ch ✉️

Nothing AG, Bern

nothing.ch/accessibility 🔗

Accessibility on the web

history, screenreaders usage and good practices in code

Hello everybody! 👋🏼

Nothing AG

Nothing AG

Our accessibility support

Reach out: josua@nothing.ch ✉️

nothing.ch/accessibility 🔗

or: Inclusive design unlocks human potential

Introduction to accessibility of digital media

20+ years ago

1808: First typewriter

1824: Braille

Modern times

Until 2010: Early digital accessibility

Today: Opportunities...

...vs. obstacles!

Most harmful situation

Two-class society in the digital world?

Public pressure increasing

Possibilities

So much is possible!

Daniele is enabled to...

Forms of disability

Unlocking human potential

Human potential is the only limitless resource we have on this earth.

Complex and accessible JavaScript widgets

(with simple HTML)

A question

of trust

What do you trust more?

Valid vs "Traditional" HTML

Benefits of traditional HTML

Sure, we can do "enhancements"

But how will it perform?

Traditional HTML beats quirky custom solutions

But why

Reason I: Ignorance

Reason I: Ignorance

Reason I: Ignorance

Reason I: Ignorance

Reason II: HTML can't be styled

Reason II: HTML can't be styled

Reason III: HTML missing

ARIA specification

ARIA example

First rule of ARIA use

Introduction to screen readers - a "gamified" approach

(to an otherwise hard-to-grasp topic)

Fog of War

Try to play Pacman...

...but with Fog of War!

Screen readers are like Pacman

but with fog of war!

Screen readers are linear (1D)

Screen readers are slow (is it?)

Screen readers:

Importance of semantics

Bad vs. good semantics

Bad vs. good semantics

Bad vs. good semantics

Litmus tests

NVDA (desktop SR)

Mobile screen readers

3 commandments

I: Reveal the Meaning

II: Instruct the ways of Interaction

III: Feedback needs to be Concise!

5min break

Take it to the test:

a closer look at custom dropdown

Google autocomplete

Google autocomplete

Amazon autocomplete

Interim conclusion

Hmmm...

Radio buttons!

A listbox

A11y Dev Guide (ADG)

ADG autosuggest