Web Accessibility for Web Developers

Web Accessibility
For Web Developers
Alexander Loechel

Accessibility
is building Bridges

Disabilities come in many forms
Visual Hearing Mobility Speech Cognitive Neural
● Cataracts
● Sun glare
● Color blind
● Low vision
● Blind
● Noise
● Ear infection
● Hard of
hearing
● Deaf
● Hands full
● Broken arm
● Spinal cord
injury
● Amelia
● Ambient noise
● Speech
impediment
● Unable to
speak
● Sleepy
● Distraction
● Migraine
● Learning
disabilities
● Autism
● Seizure
● Depression
● PTSD
● Bipolar
● Anxiety
Permanent
disability
Situational
requirement
Temporary
impairment

W3C Web Accessibility initiative (WAI)
WAI Standards:
● Web Content Accessibility Guidelines (WCAG) 2.0 (~BITV 2.0)
● Authoring Tool Accessibility Guidelines (ATAG) 2.0 Web Developer
● Accessible Rich Internet Applications (WAI-ARIA) Suite
● User Agent Accessibility Guidelines (UAAG) 2.0 Tool Developer (Browser)
● Independent User Interface (Indie UI)
● Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0
● Evaluation and Report Language (EARL) Overview

WAI - Conformance Level
● Level A (minimum level of conformance)
● Level AA (required minimum for all major pages and Baseline)
● Level AAA
Conformance is for full Web page(s) only, and cannot be achieved
if parts of a Web page is excluded
→ CMS must provide a certain level of conformance for each of its parts

WAI Conformance Claims (WCAG)
1. Date of the claim
2. Guidelines title, version and URI
"Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/"
3. Conformance level satisfied: (Level A, AA or AAA)
4. A concise description of the Web pages,
such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.
5. A list of the Web content technologies relied upon.
Conformance is defined only for Web pages. However, a conformance claim may
be made to cover one page, a series of pages, or multiple related Web pages.
→ A conformance Claim only makes sense for a certain moment in time

BITV 2.0 vs. WAI-WCAG 2.0
The German “Verordnung zur Schaffung barrierefreier Informationstechnik
nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informations-
technik-Verordnung - BITV 2.0)” is a German regulation that requires all
governmental Organisations and institutions to meet the Requirements of the
WCAG 2.0 and other WAI Standards for all
● Internet
● Intranet / Extranet
● Graphical User interfaces that are public
And additional requirements
(e.g. Explanations in easy / plain language and German sign language)

WCAG Principles
1. Perceivable
Information and user interface components must be presentable to users in
ways they can perceive.
2. Operable
User interface components and navigation must be operable.
3. Understandable
Information and the operation of user interface must be understandable.
4. Robust
Content must be robust enough that it can be interpreted reliably by a wide
variety of user agents, including assistive technologies.

Accessibility is no Rocket Science

Accessibility and SEO
goes hand in hand
What is easier for a human to understand
is easier for a machine to understand & present
and vice versa
● Valid Markup and semantic usage of Markup
○ h1-h6 for headings
● Special attribution for structured data
○ Microformats → schema.org (Person, Event, Location, ...)
○ Open Graph Protocol

Systematic Order to Implement Accessibility
1. Principle 4: Robust
4.1.1 Parsing (A)
4.1.2 Name, Role, Value (A)
2. Principle 1: Perceivable
1.4.1 Use of Colors (A) Matter of Design
1.4.3 / 1.4.6 Contrast (Minimum/Enhanced) (AA/AAA)
3. Principle 2: Operable
2.1.1 Keyboard (A)
2.1.2 No Keyboard Trap (A)
2.4.1 Bypass Blocks (A)
2.4.2 Page Titled (A)
2.4.7 Focus Visible (AA)
4. Principle 3: Understandable
3.1.1 Language of Page (A)
3.2.3 Consistent Navigation (AA)
3.3 Forms (A - AAA)
Valid semantic HTML is accessible by default;
Design could make a Website inaccessible!

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive
technologies.
Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are
nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where
the specifications allow these features. (Level A) → Validity of Markup
4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and
components generated by scripts), the name and role can be programmatically determined; states, properties, and values
that can be set by the user can be programmatically set; and notification of changes to these items is available to user
agents, including assistive technologies. (Level A) → Semantic Use of Markup
Valid & proper semantic use of Markup

sectioning
Hypertext Markup Language (HTML) Spezifikation defines basic grammar for markup information. Sectioning content defines the
structure of the Webpage and scope of context information.
Headings → <header>, <h1> - <h6> & <footer> elements are bound to scopes:
Major Scope: The whole Website:
<body> ← Sectioning root
<header>...<header>
<main>...<main>
<footer>...</footer>
</body>
Sub Scopes:
● <article>
● <aside>
● <nav>
● <section>
Each Section requires at least one heading

Principle 1: Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other
forms people need, such as large print, braille, speech, symbols or simpler language.
→ alt for images, audio and video, table descriptions, ...
Guideline 1.2 Time-based Media: Provide alternatives for time-based media.
Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without
losing information or structure.
Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from
background.
→ Color and Contrast

1.4.1 Use of Color & 1.4.3/1.4.6 Contrast
1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a
response, or distinguishing a visual element. (Level A)
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except
for the following: (Level AA)
● Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
● Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that
are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast
requirement.
● Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
1.4.6 Contrast (Enhanced): The visual presentation of text and images of text has a contrast ratio of at least 7:1, except
for the following: (Level AAA)
● Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;

Principle 2: Operable
User interface components and navigation must be operable.
Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings
for individual keystrokes, except where the underlying function requires input that depends on the path of the user's
movement and not just the endpoints. (Level A)
2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then
focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified
arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
Guideline 2.2 Enough Time: Provide users enough time to read and use content.
Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.
Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

Principle 3: Understandable
Information and the operation of user interface must be understandable.
Guideline 3.1 Readable: Make text content readable and understandable.
3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)
3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically
determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have
become part of the vernacular of the immediately surrounding text. (Level AA)
→ Information about Language, Unusual Words and Abbreviations
Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways.
→ Focus, Consistent Navigation, ...
Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.
→ Forms

Accessibility requires
care and common sense

The Zen of Python - PEP20
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
...

Conflict of Design & Accessibility
Well; Conflict of Bad Designers with Accessibility

Example special Headings
<article id="..." class="...">
<header>
<h3>
<small>Forscher zweifeln</small>
Hat es den Urknall gar nicht gegeben?
</h3>
<p class="byline">
<date class="byline_publication_date"
timestamp=”2017-12-08”>Freitag 08.12.2017</date>
 — 
<span class="byline_author">DPA</span>
</p>
</header>
<p class="abstract">Text</p>
<footer>
<h4>Related Items</h4>
<ul>...</ul>
</footer>
</article>

Example More… / Details Button
Best way restructure so that the whole
Heading and Abstract is a link
or work with “visually hidden” (Screen Reader visible) elements :
<a href="" class="btn">
Mehr…
<span class="sr-only">
zu
<span tal:replace="item/title">Artikel Titel</span>
</span>
</a>
Show for Screen Reader Only:
Bootstrap: sr-only
Zurb Foundation: show-for-sr

“The first principle is
that you must not fool yourself
- and you are the easiest
person to fool.”
Richard Feynman

The Problem of Testing
“Program testing can be used
to show the presence of bugs,
but never show their absence!”
Edsger Dijkstra
→ Testing is about responsibility & sustainability

Tools
● Browser itself:
→ Scale of text
→ Tab → Focus
● OS:
→ e.g. Mac OS X / iOS VoiceOver
● Browser Plugins
● Webtools
● Testsuites
Demo WCAG-Test / Demo Web-Relaunch

Browser Plugins
Firefox + Chrome:
● HeadingMaps (Firefox / Chrome)
● Web Developer
● Wave Browser Extension
● aXe
Firefox only
● opquast desktop
● https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/
● https://addons.mozilla.org/en-US/firefox/addon/wcag-contrast-checker/
Chrome only
● Siteimprove Accessibility Checker

More Tools
Website-Tools¶
● Wave
Color / Contrast-ratio calculators
● https://webaim.org/resources/contrastchecker/
● https://contrastchecker.com/
● http://leaverou.github.io/contrast-ratio/ <-- Nice Testing
● http://www.msfw.com/Services/ContrastRatioCalculator
Standalone Applications and Continuous Integration Frameworks
● http://asqatasun.org/
● https://github.com/paypal/AATT

Web Accessibility for Web Developers

More Related Content

What's hot

Similar to Web Accessibility for Web Developers

More from Alexander Loechel

Recently uploaded

Web Accessibility for Web Developers