indata web accessibility training - amazon s3€¦ · presented by dennis lembrée may 9, 2018...
TRANSCRIPT
Presented by Dennis LembréeMay 9, 2018
INDATA
Web Accessibility Training
for Developers
Agenda 1/2
• About @DennisL
• About You
• Intro to Accessibility
▫ Disability & AT
▫ Business Case
▫ Guidelines & Law
▫ POUR
• Web Dev Foundations
▫ 4 Layers
▫ Semantics & Order
▫ Other
• Techniques
▫ Layout/Structure
▫ Headings
▫ Images/Alt Text
▫ Forms
▫ Links
▫ Keyboard Access
▫ Tables
▫ Audio & Video
▫ About Flash
▫ About Validation
2
• Techniques cont.
▫ Design & CSS
▫ JavaScript
▫ Single Page Apps (SPAs)
▫ ARIA
Agenda 2/2
• Writing
• Testing
• Checklists
• Tools
• Manual Techniques
• Screen Readers
• HCM
• More Tips
• Resources
• Contact
• Questions
3
About @DennisL
• Senior Accessibility Consultant at Deque Systems
• Formerly on eBay and PayPal accessibility teams.
• Author of @EasyChirp and @WebAxe.
• Presented at CSUN, AHG, HTML5 Dev Conf, CSS Dev Conf, AccessU, Accessibility Summit, etc.
4
About You
• Number attending?
• How many a developer, designer, accessibility specialist, or other?
• Years of experience?
5
About Accessibility
• Disability & Assistive Technology (AT)
• Business Case
• Guidelines & Law
• POUR
6
About Accessibility
• Global Accessibility Awareness Day
• Next Thursday, May 17
• http://www.globalaccessibilityawarenessday.org
• @gbla11yday #GAAD
7
About Accessibility – Disability & AT
• Visual
• Blindness, low vision, colorblindness
• Audio
• Deafness, HOH
• Motor
• Limited ability to use a mouse or keyboard, slow response time, limited fine motor control
• Cognitive
• Learning disabilities, reading level, impaired memory
• Neurological
• Prone to seizures due to flashing
8
About Accessibility – Disability & AT
• Temporary disabilities:
• Hand in cast
• Pupils dilated at optometrist
• Ear infection
• (or went to loud concert the night before!)
• Laryngitis
• Very fatigued
• Situational disabilities:
• Broken mouse, speakers
• Carrying baby
• Sunlight
• Loud train
• Distracted by pets, telemarketer
• Low-band connection
9
About Accessibility – Disability & AT
• Inclusive Design at Microsoft + Manual
• https://www.microsoft.com/en-us/design/inclusive
10
About Accessibility – Disability & AT
• 2 videos:
• Computers and People with Sensory Impairments
• Computers and People with Mobility Impairments
11
About Accessibility – Disability & AT
• Assistive Technology - Visual
• Eye glasses
• High-contrast mode
• Screen magnifier
• Screen reader
• Braille display
12
About Accessibility – Disability & AT
• Assistive Technology - Audio
• Hearing aid
• Transcriptions
• Captions
• CART (live transcription)
13
About Accessibility – Disability & AT
• Assistive Technology - Motor
• Alternative keyboard (high-contrast, large keys)
• Onscreen keyboard
• Alternative mouse
• Switches (button, sip-puff, eye-blink)
• Mouth stick
• Head wand
14
About Accessibility – Disability & AT
• Assistive Technology - Cognitive
• Speech recognitionEx: Dragon NaturallySpeaking
• Alternative and Augmentative Communication (AAC)Ex: Proloquo2Go
• Screen readers
• Reader view modes & screen magnifiers
• (to reduce distraction)
• Word prediction
• Talking calculators
• Timers and to-do lists
15
About Accessibility – Disability & AT
• Assistive Technology - Voice Recognition
• Echo, Siri, Google Home, etc.
• People with visual disabilities (typing on touch device)
• People with physical disabilities
• People with cognitive disabilities
• Convenience!
• NOTE:These services should also provide a text input alternative for people with a speech impairment.
16
Check on Learning
• What are the 5 types of disability?
• What are some examples of assistive technology?
17
• Video demos
• JAWS Screen Reader - Hear an Example
• How screen readers speak a simple HTML5 page
About Accessibility – Disability & AT
18
• Build empathy with simulation exercises:
• Keyboard only (unplug mouse!)
• Take off glasses or wear wrong prescription.
• Wear vision simulation goggles.
• Put rubber band on your off-hand; use with mouse.
• Wear mittens/gloves.
• Straw test (or increase text size or zoom by 200% or more)
• Set very fast mouse pointer.
• Set very high browser zoom.
• Turn off audio (with multimedia).
About Accessibility – Disability & AT
19
• Increases potential customer base.
• Creates usability benefits for people with and without disabilities, including the increasing aging population.
• Reduces development and operational costs (server load, bandwidth, and maintenance).
• Improves cross-device browsing, including mobile phones, interactive television, and other delivery channels. (Robust)
• Reduces need for customer service.
About Accessibility – Business Case
20
• Avoids possible legal ramifications of not implementing web accessibility.
• Creates social acceptance; corporate social responsibility.
• Eliminates need to provide alternative webpage and media formats (braille, large print, CD, etc).
• Search Engine Optimization (SEO).
About Accessibility – Business Case
21
• W3C
• World Wide Web Consortium
• WAI
• Web Accessibility Initiative
• https://www.w3.org/WAI/
• WCAG
• Web Content Accessibility Guidelines 2.0
• https://www.w3.org/TR/WCAG20/
About Accessibility – Guidelines & Law
22
• WCAG 1.0 (1999)
• WCAG 2.0 (2008)
• Technology-agnostic.
• WebAIM’s WCAG 2.0 Suggestions
• WebAIM's WCAG 2.0 Checklist
• WCAG 2.1
• W3C Candidate Recommendation 30 January 2018
• Adds mostly mobile and cognitive guidelines
• https://www.w3.org/TR/WCAG21/
About Accessibility – Guidelines & Law
23
• U.S.
• Americans with Disabilities Act (ADA) 1990
• Rehabilitation Act Amendments of 1998, Section 504 & Section 508 (part of Rehabilitation Act of 1973)
• Enforceable in June 2001
• Updated Jan. 18, 2017
• Adopts WCAG 2.0 AA for new content
• Air Carrier Access Act (ACAA)
• Websites, kiosk, phone, etc.
• Doesn’t cover mobile
About Accessibility – Guidelines & Law
24
• U.S. — lawsuits and settlements
• Target, 2008
• In 2017, at least 814 federal lawsuits on inaccessible websites
• University, finance, retail, municipality
• Follow Lainey Feingold @LFLegal
• http://www.lflegal.com/2018/03/csun18-follow-up/
• More: http://bit.ly/a11ylawsuits
About Accessibility – Guidelines & Law
25
• UK
• The Disability Discrimination Act 1995 (DDA)
• Special Educational Needs and Disability Act 2001
• PAS 78 – guide by British Standards Institution (BSI) & Disability Rights Commission (DRC)
• Australia
• Disability Discrimination Act 1992
• Canada
• Canadian Human Rights Act of 1977
• World policies – http://www.w3.org/WAI/Policy/
About Accessibility – Guidelines & Law
26
• What are some business reasons for providing web accessibility?
Check on Learning
27
POUR:
(unfortunate) acronym for the 4 WCAG principles
• Perceivable
• Operable
• Understandable
• Robust
About Accessibility – POUR
28
• Perceivable
• Available to the senses (vision and hearing primarily) either through the browser or through assistive technologies (e.g. screen readers, screen enlargers, etc.)
About Accessibility – POUR
29
P
• Perceivable
• Provide text alternatives for images, etc.
• Provide captions and transcripts for video and audio.
• Present content in different ways.
• Design with proficient color contrast.
• Avoid movement and distractions on page.
About Accessibility – POUR
30
P
• Operable
• Users can interact with all controls and interactive elements using either the mouse, keyboard, or an assistive device.
• Important for mobile devices and IoT!
About Accessibility – POUR
31
O
• Operable
• All functionality is available from the keyboard.
• Users have control over timing and limits.
• Do not cause seizures (don’t flash content ~> 3x per sec).
• Provide multiple ways to help users navigate, find content, and determine where they are.
About Accessibility – POUR
32
O
• Understandable
• Content is clear and limits confusion and ambiguity.
About Accessibility – POUR
33
U
• Understandable
• Economical and plain use of language.
• Text supplemented with illustrations, videos, and other formats.
• Navigation, information structure are obvious and consistent.
• Make pages operate in predictable ways.
• Help users avoid and correct mistakes.
About Accessibility – POUR
34
U
• Robust
• A wide range of technologies (including old and new user agents and assistive technologies) can access the content.
About Accessibility – POUR
35
R
• Robust
• Functional across various technologies.
• Providing a name, role, and value for non-standard user interface components.
• Adhering to W3C standards ensures future compatibility.
• Validate your code - validator.w3c.org
• Use semantic markup.
• Use progressive enhancement (PE).
About Accessibility – POUR
36
R
Check on Learning
• What does POUR stand for?
37
Foundations
• 4 Layers
• Semantics & Order
• Other
38
Foundations – 4 Layers
1. HTML – be POSH!Plain Ol’ Semantic Html
2. CSS – style
3. JavaScript – to enhance behavior
4. ARIA – accessibility helper
39
Foundations – 4 Layers
40
Foundations – Semantics & Order
• Semantics
• Use HTML element that describes the content (not presentation)
• Good for:
• Accessibility
• Graceful degradation
• Future-proofing
• Easier to maintain (standard, consistency)
• SEO
• Professionalism
41
Foundations – Semantics & Order
Content Order = Source Order = Tab Order
42
Foundations – Other
• Use strong/em elements for importance/emphasis/delete; not CSS.
• If very important (such as sale price), must correct for screen reader users.
• Tweaking Text Level Styles by Adrian Roselli: http://bit.ly/a11ytext
• Never use an element for its design, for ex:
▫ X Blockquote for the indent.
▫ X Headings for the bold.
• Forms:
▫ Placeholder is not a label.
▫ If one selection required, use radio, not checkbox.
▫ Label groups of radio inputs and checkboxes.
43
Check on Learning
• What are the 4 layers of web accessibility code?
• Content Order = Source Order = ?
44
Techniques
• Layout/Structure
• Headings
• Images/Alt Text
• Forms
• Links
• Keyboard Access
• Tables
• Audio & Video
• About Flash
• About Validation
• Design & CSS
• JavaScript
• Single Page Apps (SPAs)
• ARIA
45
Techniques – Layout/Structure
• Visually consistent
• The main areas of the page—such as the banner, navigation, and sidebar—should be in the same place throughout the site.
• Consistent markup
• The areas should also be marked up consistently, such as using the same heading structure.
• Good usability and benefits those with cognitive impairments and those who use AT.
46
Techniques – Layout/Structure
Don’t disable pinch zoom.
No
<meta name="viewport" content="width=device-width, initial-scale=1,
maximum-scale=1, user-scalable=0">
Yes
<meta name="viewport" content="width=device-width, initial-scale=1,
user-scalable=1">
Meta viewport by PPK:http://www.quirksmode.org/mobile/metaviewport/
47
Techniques – Layout/Structure
Define page language with lang attribute.
Page level
<html lang=“en”>
Inline
Switch language to <a href=“foo” lang=“fr”>français</a>.
More:http://adrianroselli.com/2015/01/on-use-of-lang-attribute.html
48
Techniques – Layout/Structure
Skip-to links
• For keyboard user to jump over groups of repetitive links.
• “Skip to main” most popular .
• Also needed for things like search/filter bars.
• Mostly for sighted keyboard users.
• SkipTo plugin by PayPal Accessibility Team• http://paypal.github.io/skipto/
49
Techniques – Headings
• Use one H1 per page.
• Brief, succinct text.
• Properly nested (H1 > H2 > H3).
• Use a heading with <section> element.
• Can use heading within Legend.
• Use proper semantics!
• Wrong: <span style="font-size:2em"><b>My Page Title</b></span>
• Right: <h1>My Page Title</h1>
50
Techniques – Headings
51
Techniques – Images/Alt Text
• Provide alternative text for images that have with meaningful content.
• Fundamental but complex!
• Needed badly on infographics, graphical charts, and comics.
52
Alt text?
[Poll]
Techniques – Images/Alt Text
• If decorative, use alt=“” (or use CSS background).
• If same content exists in page text, use alt=“”.
• If image linked, alt text should describe purpose of link.
• Be accurate and succinct.
• Usually don’t need phrases like “image of…”
• Avoid text in images.
• Consider using CSS3 or SVG instead of a rasterized image.
53
Techniques – Images/Alt Text
54
Techniques – Images/Alt Text
• In HTML5, alt optional with figure/figcaption
• I consider this a poor recommendation.
• Captions and alt text are often two different meanings.
• Do this:
<figure>
<img src="shadows.jpg" alt="Human figures and graffiti tag painted on
deteriorating wall lit by streetlamp" />
<figcaption>Photo by Alfred Numen circa 1992</figcaption>
</figure>
55
Techniques – Images/Alt Text
For long text descriptions:
• Strongly suggest putting on page (or linking to page).
• Optionally can use longdesc, aria-describedby, aria-details (ARIA 1.1).
• None of these are perfect.
• Only aria-describedby is well supported but points on-page content anyway.
<img src=”dogs.jpg” alt=”two ugly dogs” aria-describedby=”dogsDesc” />
56
Techniques – Forms
• Labels
• Fieldset/legend
• Messages (errors, required information)
57
Techniques – Forms
• Labels
▫ All form elements must have a label.
▫ Best to align label above input (mobile, screen magnifier).
▫ Other methods such as title and placeholder are NOT robust.
▫ Use for and ID attributes to associated (not name).
<label for="firstname">First Name</label>
<input name="firstname" id="firstname" type="text" />
58
Techniques – Forms
• About “floating labels”
▫ Will pass WCAG 2.0 AA audit if
▫ Coded correctly
▫ Visual label doesn’t disappear
▫ Color contrast is sufficient
▫ Not recommended by me but a good compromise
59
Techniques – Forms
• Fieldset/legend
• Great for long forms and radio/checkbox groups.
• Screen readers will announce Legend text before each label text within Fieldset.
• Legend text should be brief & succinct.
<fieldset>
<legend>Your Gender</legend>
<label for="male">Male</label>
<input name="gender" id="male" value="male" type="radio" />
<label for="female">Female</label>
<input name="gender" id="female" value="female" type="radio" />
</fieldset>
60
Techniques – Forms
• Alternative method to Fieldset, especially for long Legend text:
<p id="question">What is the name of…</p>
<div role="radiogroup" aria-labelledby="question">
<input…><label…>
<input…><label…>
</div>
61
Techniques – Forms
• Messages
▫ Use aria-describedby for screen readers
<label for="address">Address</label>
<input name="address" id="address" type="text" aria-
describedby="hintAddr" />
<p id="hintAddr">Your primary residence.</p>
62
63
<form action="foo.php" method="post">
<fieldset>
<legend>Location</legend>
<p id="hintAddr">Where you are now.</p>
<label for="address">Address</label>
<input name="address" id="address" type="text" aria-
describedby="hintAddr" />
<label for="city">City</label>
<input name="city" id="city" type="text" aria-describedby="hint" />
</fieldset>
</form>
Techniques – Forms
64
Techniques – Links
• Link vs. Button
• Content (the link text itself)
• Awareness
• About title/tooltip
Reduce cognitive load!
• Proper role (design and code) provides predictable behavior for users
• Especially helpful for screen reader users
65
Techniques – Links
Link vs. Button
• Buttons do action (submit form, open dialog, show/hide content).
• Links go to URL (full page, page anchor, file).
• Don’t recreate a button.
• Customizing means recreating all native behavior (focus, role, keyboard) .
• Role=button used as last resort OR progressive enhancement.
66
Techniques – Links
Link vs. Button
• Also a design issue.
• Consistent design/functionality particularly helps voice-control UI.
• More: http://bit.ly/linkbutton
67
Techniques – Links
• Content (the link text itself)
• A link should always have meaning when taken out of context.
• A text link should be unique to that page (do not use the same link text for different resources).
• Avoid use of "click here", "more", etc.
• Do not write out and link a long URL
• bad readability
• annoying to screen reader users
68
Techniques – Links
• Awareness
• Is this a link? Keep the underline!
• Visually indicate when in focus (as well as on hover).
• Indicate type of link (if not regular hyperlink, e.g. PDF, MP4, etc).
<a href=“poster.pdf”>Download Poster (PDF)</a>
69
70
Techniques – Links
• Warning on title attribute (tooltip)
• In screen reader settings, title is often turn off.
• No keyboard support (silly browsers!)
• No support on touch devices.
• Assume the user may only sometimes read them.
• Use for supplementary content only.
• Use sparingly.
• DO NOT create redundant titles on links.
• NOTE: Title attribute is good for iframes and <abbr>
71
Techniques – Links
• Enhancing the title attribute (tooltip)
• Make keyboard accessible
• Make more readable/customizable
• Use aria-describedby and role="tooltip"
• Resources
• https://a11y.nicolas-hoffmann.net/simple-tooltip/
• http://ianmcburnie.github.io/mindpatterns/disclosure/tooltip/
• http://oaa-accessibility.org/examplep/tooltip1/
72
Techniques – Keyboard Access
• Many web users do not use a mouse.
• Assistive technologies frequently make use of keyboard input or even a virtual keyboard instead of a mouse or pointing device.
• Links and controls cannot require a mouse.
73
Techniques – Keyboard Access
• In CSS, use :focus together with :hovera:hover,
a:focus {
background-color: #ccc;
}
• Never use outline none (unless y’all want much more work):a:focus {
outline: none;
}
74
Techniques – Keyboard Access
• It's always best to stick with the standard A element.
• Wrong: <span onclick="window.location='foo.html';">
foobar</span>
• Right: <a href="foo.html">foobar</a>
75
Techniques – Keyboard Access
• For the tabindex attribute, avoid positive integer values (tabindex>0).
• tabindex="0”
• use with discretion
• makes elements besides links and form elements to receive keyboard focus.
• tabindex="-1"• use with discretion
• makes elements besides links and form elements to receive programmatic focus (by scripting, link, etc.)
76
Techniques – Keyboard Access
Interaction patterns:
• Enter activates links and buttons.
• Enter and spacebar activates buttons.
77
Techniques – Keyboard Access
Widget interaction patterns:
• Enter or Spacebar to open.
• Up/down arrow keys to select options.
• Escape to close.
• Tab closes and focuses next item on page.
Demo: http://bit.ly/a11ymenubutton
78
Techniques – Tables
• Provide caption (title of table).
• The summary attribute not recommended.
• Main purpose, define structure of table, no longer needed.
• Obsolete in HTML5.
• Difficult to maintain.
• Instead use aria-describedby with Paragraph.
• If you must table for layout, fix with ARIA:
• <table role=“presentation”>
79
Techniques – Tables, cont.
• Use TH for table header cells.
• May add scope attributes to TH to support older AT.
• Never nest data tables.
• Avoid complex data tables if possible.
• Use headers and id attributes if necessary.
80
Techniques – Tables, cont.
81
Tacos
Techniques – Tables, cont.
82
Mon Tue Wed Thu Fri
Breakfast
Lunch Tacos
Dinner
83
<p id="tableDesc">The following table displays the number of employees and
the foundation year of some imaginary companies.</p>
<table aria-describedby="tableDesc" tabindex="0">
<caption>Company Data</caption>
<tr>
<th scope="col" abbr="Company">Company Name</th>
<th scope="col" abbr="Employees">Number of Employees</th>
<th scope="col" abbr="Founded">Year Founded</th>
</tr>
<tr>
<th scope="row">ACME Inc</th>
<td>1000</td>
<td>1947</td>
</tr>
<tr>
<th scope="row">XYZ Corp</th>
<td>3000</td>
<td>1973</td>
</tr>
</table>
Techniques – Tables, cont.
• VideoAccessibility: Web Apps: Tables
84
Techniques – Audio & Video
• HTML5
• Multiple formats required due to differences in browser support.
• Ensure controls are accessible.
• Browser vendors slowing making progress.
• Track element for audio descriptions, captioning, subtitles, etc. (low support).
85
Techniques – Audio & Video
• HTML5 <audio> and <video>
• Check browser support.
• http://caniuse.com/
• http://html5please.com/
• Check codec support:
• http://mzl.la/Mn6tlp (MDN)
• http://bit.ly/Mn6wxN (HTML5Doctor)
86
Techniques – Audio & Video
HTML5 Code
<video id="video" width="500" height="300" preload="none" poster="cover.jpg"
autoplay="false" >
<source src="somevideo.webm" type="video/webm">
<source src="somevideo.mp4" type="video/mp4">
<p>Video not supported. You may <a href="foo.mpg">download the MPG
here</a>.</p>
</video>
87
Techniques – Audio & Video
• Accessible HTML5 Video Player by PayPal http://bit.ly/1oxpjTV
• Ind.ie: http://bit.ly/1GHi70U
• Plyr: https://plyr.io
• More: http://bit.ly/a11yvideo
88
Techniques – Audio & Video
• Transcriptions, captions
• Why:
• Deaf
• hard-of-hearing
• language is not user’s native
• learning-impaired
• broken speakers
• in library
• SEO
89
Techniques – Audio & Video
• Transcriptions, captions
• Tools:
• dotSUB.com
• Overstream.net
• Easy YouTube caption creator
• MAGpie
• Captionate (Flash)
90
Techniques – Audio & Video
• Transcriptions, captions
• Services:
• Casting Words: http://castingwords.com/
• Rev: https://www.rev.com/transcription
• Dragon Naturally Speaking
• Volunteers, interns
91
Techniques – Audio & Video
• Captioning tips:
• Should be accurate, consistent, clear, readable.
• Mixed case preferred, but use upper case for emphasis and shouting.
• Meaningful sound effects should be included.
• Denote when speaker has inflection/mood. [whispering]
• When a speaker cannot be identified, user gender to describe (e.g., “female 1,” “male narrator”).
• For video-only clips, provide a note saying "No sound is used in this clip".
92
Techniques – Audio & Video
• Audio description:
• AKA video description
• Also a WCAG AA requirement (for recorded video)
• Adds narration of what’s visually happening onscreen
• Learn more: http://www.acb.org/adp/ad.html
• Services: 3Play Media, Video Caption Corp.
• Frozen trailer example: https://youtu.be/O7j4_aP8dWA
93
Techniques – About Flash
• According to screen reader users, Flash content is one of most inaccessible items on the web.
• Adobe has worked hard to make it possible to create accessible Flash, but in Windows only!
• But in practice, frankly speaking, developers rarely do it.
94
Techniques – About Flash
• Avoid Flash.
• Make every attempt to develop Flash with accessibility.
• If it's not possible for whatever reason, be sure to provide alternate content.
• A great example of accessible Flash is this entertaining piece by Inclusive Technologies (direct Flash file link): Assistive Technology Boogie.
• It's keyboard accessible, provides captioning, and an option for audio description.
95
Techniques – About Validation
• Important for interoperability, but don’t go overboard.
• Tools
• W3C Markup Validation Service
• HTML Validator for Firefox
• Some design/developer applications such as Dreamweaver.
• User experience is ultimate test.
96
Techniques – Design & CSS
Readability
• Rendered text size of 16px+
• relative units preferred
• Medium weight font
• Ample line height (1.3-1.5)
• Medium line length (50-65 characters)
• Ample white space and margins
• Avoid centering blocks of text
• Avoid justified text
• Sufficient color contrast*
• Proximity
97
Techniques – Design & CSS
Sufficient color contrast (WCAG 1.4.3)
• Regular text:
• Regular text and images of regular text MUST have a contrast ratio of at least 4.5 to 1 with the background.
• Large text:
• Large text and images of large text (at or over 18 point or 14 point bold) MUST have a contrast ratio of at least 3 to 1 with the background.
98
Techniques – Design & CSS
Ample hit areas
WCAG 2.1 says “44x44 CSS pixels”
https://www.w3.org/TR/WCAG21/#target-size
• Unless:• Another equivalent
• Inline (block of text)
• Target is determined by the user agent (not author)
• Essential to the information being conveyed
• Use padding not margin around links
99
Techniques – Design & CSS
Hiding Content
Do not use display:none for content specific to screen reader users.
Use off-screen (good for skip-to).visually-hide {
position: absolute;
left: -9999em;
}
Use clipping (better for screen readers on touch-screen devices and RTL language support).visually-hide {
position: absolute;
clip: rect(1px, 1px, 1px, 1px);
}
100
Techniques – Design & CSS
.visually-hide {
position: absolute !important;
clip: rect(1px, 1px, 1px, 1px) !important;
-webkit-clip-path: inset(50%) !important;
clip-path: inset(50%) !important;
padding: 0 !important;
border: 0 !important;
height: 1px !important;
width: 1px !important;
white-space: nowrap !important;
overflow: hidden !important;
}
101
Techniques – Design & CSS
CSS-Generated Content
Don’t do:
<a href="#foo" class="icon-gear">
<span class="visually-hide">options</span>
</a>
Do:
<a href="#foo">
<span aria-hidden="true" class="icon-gear"></span>
<span class="visually-hide">options</span>
</a>
102
The CSS:.icon-gear:before {
content: "\29";
}
Techniques – Design & CSS
CSS-Generated Content
SVG, Icon Fonts, and Accessibility: A Case Study
• http://bit.ly/icon-a11y
• From “24 Accessibility” series
103
Techniques – Design & CSS
CSS-Generated Content
Screen reader support for SVG is inconsistent.
• SVG Test Page: http://bit.ly/svgsr
104
Techniques – Design & CSS
Recap:
• Make text readable
• Provide ample hit areas
• Hide content appropriately
• Be careful with SVG and CSS-generated content
As mentioned earlier:
• Use :focus together with :hover
• Avoid :focus { outline: none; }
• Don’t disable zoom!
105
Techniques – Design & CSS
More resources:
• Inclusive Design: 12 Ways to Design for Everyone: http://bit.ly/2K15Cpe
• Your Interactive Makes Me Sick: http://bit.ly/2K1e6g0
• A Primer to Web Accessibility for Designers: http://bit.ly/2K1s3dE
• Designing For Accessibility And Inclusion: http://bit.ly/2K1CaPY
• Inclusive Design Fundamentals (CSUN 2017): http://bit.ly/2K1CgqO
106
Techniques – JavaScript
• Use Progressive Enhancement when possible• May be a business decision
• Provide essential functionality/content first
• More of usability issue but can be accessibility issue in some cases
• Don’t use when not needed• Submit form, scroll page, autofocus, etc.
• Test with keyboard, then bridge screen reader gaps with ARIA
107
Techniques – JavaScript
• Always manage focus!
• Essential for accessibility as well as usability.
• Show/hide content e.g. modals, side panels
• Components such as autosuggest, menus, tabpanels
• Deleting content e.g. messages, etc.
• tabindex
• tabindex=0 makes element tabbable
• tabindex=-1 makes element tabbable only with JavaScript
• Don’t use otherwise.
108
Techniques – JavaScript
• Device Independence
• Avoid onMouseOver, onMouseOut, onDblClick.
• Better to use native components
• Save all teams a lot of work!
• Not keyboard accessible: <a onClick=foo()>Next Page</a>
• Adds code weight and complexity
• Doesn’t degrade gracefully
109
Techniques – SPAs
• SPA: Single Page Application
• Frameworks such as
• Angular
• React
• Ember
• Backbone
• Breaks conventions of web site behavior
110
Techniques – SPAs
• Implementing as SPA is not an excuse to neglect semantic markup
• and other good coding practices such as
• Page structure
• Focus management
• Properly hiding content
111
Techniques – SPAs
• AT must be notified when new “pages” are loaded.
• Not be silent but read something logical (such as updated H1).
• AT must be notified for other content changes.
• Alert messages, important content updates
• Remember focus management during dynamic content changes.
• Page title must update, if appropriate.
• Ensure functionality of browser Back/Next buttons.
• Properly hiding content from assistive technology that isn't visible on the current page.
112
Techniques – SPAs
• A few resources for accessible SPAs:
• Official React Accessibility page: https://reactjs.org/docs/accessibility.html
• Creating accessible React apps: http://simplyaccessible.com/article/react-a11y/
• Testing for accessibility in Angular 1 and 2: https://youtu.be/9y2MnXo45cs
• Building an Accessible Ember App: http://bit.ly/a11yEmber
• A React Design System: https://sforce.co/2K0VBs4
113
Techniques – ARIA
• Accessible Rich Internet Applications (WAI-ARIA) 1.0http://www.w3.org/TR/wai-aria/
• Roles
• Widget, Landmark, Document Structure
• States and Properties
• Widget, Live Region, Drag-and-Drop, Relationship
• ARIA 1.1
• W3C Recommendation 14 December 2017
114
Techniques – ARIA
• Attributes that define user interface elements to improve the accessibility and interoperability of web content and applications.
• Rule #1:
If you can use a native HTML element or attribute instead of an ARIA role, state or property, then do so.
115
Techniques – ARIA
• ARIA provides not functionality; still must build in with scripting.
• Adding an ARIA role overrides the native role semantics.
• Adding ARIA:
• in HTML (for landmarks, labeling and describing)
• with JavaScript (for widgets)
116
Techniques – ARIA
• Some quirks:
• Tab is not a main navigation tab (but tab panel)
• Menu is not a navigation/link menu (but dropdown with actions like desktop application)
• Banner and contentinfo should only be used once per page
• HTML5 required vs aria-required—use both
• longdesc vs. aria-describedby vs. aria-details
117
Techniques – ARIA
• Don’t use role="application" (very few exceptions)
• Puts AT user in forms mode.
• Some ARIA elements application role by default (tabs, dialog, menu, etc.)
• Most likely don’t need to use role="form"
118
Techniques – ARIA
• Use role="presentation" to repair parent-child relationships.
• Removes the semantics from the element.
119
<div role=“menu”>
<ul role=“presentation”>
<li role=“menuitem”>Foo</li>
<li role=“menuitem”>Bar</li>
</ul>
</div>
Techniques – ARIA
• For example, this:<h1 role="presentation">text</h1>
• becomes this:<>text</>
120
Techniques – ARIA Live Regions
• For AJAX implement Live Regions.
• aria-live (property)
• off, polite, assertive
• aria-busy (state)
• aria-atomic (property)
• aria-relevant (property)
122
Techniques – ARIA Live Regions
123
Techniques – ARIA States
• aria-checked (state)
• Indicates the current "checked" state of checkboxes, radio buttons, and other widgets.
• aria-expanded (state)
• Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.
• Show/hide controls, menus
124
Techniques – ARIA Properties
• aria-describedby (property)
• Associates descriptive text with an element (not name/label).
• aria-labelledby AND aria-label (property)
• Label/name form controls, landmarks, modal windows, etc.
• Use aria-labelledby with onscreen text
• aria-required (property)
• Like HTML5 required.
• aria-valuemax, aria-valuemin (properties)
• Defines the minimum and maximum values for a range widget.
125
Techniques – ARIA Properties
Highlights in ARIA 1.1
• aria-current (state)
• Indicates the element that represents the current item within a container or set of related elements.
• aria-modal (property)
• Indicates whether an element is modal when displayed.
• AT may limit navigation to the modal element's contents.
• aria-haspopup (property)
• Indicates the availability and type of interactive popup element.
• Value options extended to: menu, listbox, dialog, tree, grid.
126
Techniques – ARIA landmark roles
• role =• banner (page header - one per page)
• navigation (nav)
• main (main, div - one per page)
• complementary (aside)
• search (form, div)
• contentinfo (page footer - one per page)
• form, application [rare]
• Use all (except main) for backwards compatibility
127
Techniques – ARIA landmark roles
128
<header role=“banner”>
<nav role=“navigation”>
<footer role=“contentinfo”>
<div role=“main”><aside
role=“complementary”>
<form role=“search”>
Techniques – ARIA landmark roles
• VideoHow ARIA landmark roles help screen reader users
129
Check on Learning
• What are the 3 states of a live region?
• Name 4 landmark roles
130
Writing
• Use short sentences.
• Use short paragraphs.
• Favor the active voice over passive voice.
• Do not use jargon, slang or idiomatic phrases.
131
Writing, cont.
• Avoid directional language.
• “In the links to the left…”
• Don’t convey meaning with color alone.
• “Click the green button to…”
132
Writing, cont.
• Provide definitions of technical terms.
• Provide full terms for lesser known acronyms and abbreviations
• Write full text at least once on page.
• Use abbr element; acronym deprecated.
<p>I leased a new <abbr title=“Volkswagen”>VW</abbr>.</p>
133
Writing, cont.
• Page title (descriptive, concise, unique)
• Headings (descriptive, concise, unique)
• Labels for multiple navigation blocks
134
Writing, cont.
• Alternative text for images
• Decorative or use CSS? Linked? Already on page?
• Captions & transcripts
• Form Legends and Labels (brief and succinct)
• Links:
• Descriptive link text (meaningful on own)
• Notify user when linking to anything other than an HTML page
• Notify user when opening a new window
135
Check on Learning
• What is the element and attribute used for an acronym?
136
Testing
• Use multiple avenues to test
• Do what works for you and for your organization
• QA:
• Checklists
• Tool
• Manual techniques
• Screen readers
• High-contrast mode
137
Testing
But first…
Devs:
• Continuous integration (CI)
• @MarcySutton
• https://marcysutton.github.io/a11y-and-ci/#/
• https://www.youtube.com/watch?v=9x-MRZEEONE
138
Testing - Checklists
• Useful or not?
• Yes, a great starting point.
• Examples:
• WebAIM: https://webaim.org/standards/wcag/checklist
• The A11y Project: https://a11yproject.com/checklist
• Paul Adam: http://pauljadam.com/wcag20checklist.html
• More from Web Axe: http://www.webaxe.org/wcag-cheat-sheets/
• Internal/custom
139
Testing - Tools
• Color contrast tools
• See Web Axe list: http://www.webaxe.org/color-contrast-tools/
▫ Websites
▫ Browser add-ons
▫ Standalones
140
Testing - Tools
• Toolbars are useful for everyone.
• Examples:
▫ aXe (Deque Systems)
▫ WAVE (by WebAIM)
▫ WAT (IE, Opera by TPG)
▫ Web Developer Toolbar (Firefox, Chrome)
▫ Accessibility Developer Tools (Chrome)
▫ Now included by default (audit, inspector)
141
Testing - Tools
• Automated testing is great for:
• “Easy” catches and large projects
• Monitoring status/progress
• Alone catches only ~35-50% of issues.
• Examples:
▫ aXe & WorldSpace (Deque Systems)
▫ Tenon.io (w/Node.js)
▫ WAVE API (by WebAIM)
▫ SiteImprove
142
Testing - Manual Techniques
▫ Keyboard
▫ Functionality
▫ Focus order/management
▫ Visual focus indicator
▫ Similar text between page title and H1
• Text zoom (150 vs 200%)
• Transcripts, captions, audio description
• Adequate text size (14px+)
143
Testing - Manual Techniques
• Layout and navigation consistency
• Not using color alone to convey meaning
• Check document outline (heading structure)
• Check on different browsers and screen sizes
• Check on different devices and AT
• Reading level
144
Testing - Manual Techniques
Bonus!
• Text-only browser such as Lynx
• Turn off JavaScript
• Turn off CSS
145
Testing - Screen Readers
• NVDA (Windows, free) + Firefox
• JAWS (Windows) + IE
• VoiceOver (comes with OS X, iOS) + Safari
• Tutorials/cheat sheets:
• WebAIM: http://webaim.org/articles/nvda/ (also JAWS, VO)
• Deque: https://dequeuniversity.com/screenreaders/
• TPG: http://bit.ly/1UN8xnF
• Accessibility Testing with the NVDA screen reader: https://youtu.be/Vx1vSd5uYS8
146
Testing - Screen Readers
• TalkBack
• Ships with Android
• Use with Chrome
• Narrator
• Comes with Windows 10
• Window-Eyes
• Free to users of Microsoft Office
• Fangs
• Firefox add-on which simulates screen reader output with text output.
147
Testing - HCM
• High contrast mode
• Windows shortcut: ALT+LEFT SHIFT+PRTSCN
• Mac: System Preferences > Accessibility > Display > select “Invert Colors”
148
Check on Learning
• Name some accessibility toolbars and automated tools.
149
More Tips
• Plan accessibility from the very start.
• Get all teams involved
• Wireframes, content, QA, etc.
• Organization talking embedding accessibility culture: http://bit.ly/a11yCulture
• NVDA and VoiceOver screen readers are free.
• Learn last IMO
• Error handling is very important (esp. if legal or financial related).
• And preventing errors
• Sometimes there won’t be perfect solution to an accessibility problem.
• Sometimes the solution is subjective.
150
Resources
• List of Lists! http://bit.ly/a11yLists
• Organizations:• INDATA, Deque Systems, WebAIM, IBM, Microsoft, The Paciello Group,
Knowbility, Level Access, AbilityNet, AccessibilityOz, Shopify
• People: too many to name, check Twitter!• Hash tags such as #a11y
• Twitter lists
• Not a tweep? Try: Facebook.com/WebAxe
• YouTube channels• Dennis’ Accessibility channel
• DO-IT
• We Are Nomensa
151
Resources, cont.
• W3C Web Accessibility Tutorials:
• https://www.w3.org/WAI/tutorials/
• Email newsletters:
• http://www.webaxe.org/digital-accessibility-newsletters/
• Patterns:
• eBay MIND Patterns
• U.S. Web Design System
• Deque Code Library
• Inclusive Components blog
• Books:
• http://www.webaxe.org/web-accessibility-books/
152
Contact
• Websites
• EasyChirp.com
• WebAxe.org
• DennisLembree.com
• Twitter Accounts
• @EasyChirp
• @WebAxe
• @DennisL
153
Questions?
154