accessibility and universal usability
TRANSCRIPT
Accessibility and universal usability
Developing websites that everyone can use
Basics
TerminologyAccessibility: Ensuring that users with disabilities and impairments can successfully navigate and use websites and software.
Universal Usability: Similar to Accessibility, but pertains more to design (usability + user centered design). It includes use cases for people with disabilities, mobile devices, different environments & different input devices.
Semantics/Semantic Structure: Writing HTML in a way that gives meaning to each element – meaning that the browser can derive the element’s purpose from.
Terminology, cont.WAI: Web Accessibility Initiative – group by the W3C to improve Accessibility on the web
ADA: American Disability Act (Will hear ADA Compliant)
AT: Assistive Technology – tools (hardware or software) to help people with disabilities use computers
Section 508: Passed in 1998 as an amendment to an act from 1973, to ensure that IT developed, purchased, and used by the Federal government is made accessible to everyone.
Types of Disabilities• Visual: Blind, legally blind, colorblind, difficulty
seeing
• Cognitive: Autism, dyslexia, seizures, language barriers, learning disorders, vestibular disorders, mental illness that affects comprehension and perceptions
• Motor: Parkinson’s (and tremors), paralysis, arthritis, spinal cord injury
• Hearing: Deaf or hard of hearing
Types of AT• Screen magnifiers• Screen readers & refreshable Braille displays• Text-to-speech software• Speech recognition software• Alternate inputs (i.e., head pointers, on-screen
keyboards, single switch, sip/puff)• Alternate pointing devices
Conformance LevelsLevel A: All A conformance met. Examples: Non-text has text equivalent
(alt text), captions (video), labels and controls programmatically related, use of color, etc.
Level AA: All A and AA conformance met. Recommended conformance level for most corporations. Examples: Audio description (videos), contrast (4.5: 1), resize text (up to 200%).
Level AAA: All A, AA, and AAA conformance met. Examples: 3 flashes or below threshold (video, gifs), low to no background noise (video, audio), sign language equivalent (video, audio).
Reference: How to meet WCAG 2 conformance rules
UI Considerations• Key information should be discernable at a glance• Clear hierarchy of information via headings + paragraphs• Don’t rely on color to tell your story • Viewport should not be locked at maximum-scale=1.0• Color contrast should be decent between foreground &
background• Focus should outline elements• Text should be large enough to be readable• Forms should use more than an asterisk to indicate field
is required
UI Considerations, CONT.• Forms: Error messaging should not just use color to indicate• Forms: Controls large enough to easily click into• Forms: Labels tied to controls, so selecting label checks
small checkboxes & radio btns• Buttons: Large enough to click (minimum is 36px, comfortable
size is 44px)• Buttons: Far enough apart to be easily clickable w/o making
mistakes• Focused elements: Additional styling for contrast• Descriptive text and calls to action
UI Considerations, CONT.• Sketch: Plugin for Color Contrast Analyzer• Photoshop: Plugin for Color Blindness/Deficiency• Google Material Design -- Usability section with
Guidelines
• Apple’s User Interface Guidelines
Intro to the Accessibility Tree• A subset of the DOM tree and represents structure of the UI
• Accessibility API creates accessible objects (aka nodes) for every DOM elm to be exposed to AT (i.e, checkbox, radio button)
• Provides information about events to AT to interact with widgets (including the Accessible Name and Accessible Description)
• Can use an object inspector like aViewer, XCode’s Accessibility Inspector, or Chrome has built in accessibility: chrome://accessibility
ARIA -- Accessible Rich Internet ApplicationsUsed for AJAX, forms, dynamic content changes, etc.
• ARIA properties: extend HTML elms
• Aria-required: Ensures AT is aware the control is required• Aria-live: Dynamic content which updates without a page reload• Aria-labelledby: Establishes relationship between objects and their
label(s).
• Aria-describedby: Similar to aria-labelledby, although the previous describes the essence of an object, while a description provides more information that the user might need.
• Aria-hidden: Hides the element from AT, so it won’t be read or focused.
Reference: Mozilla ARIA Documentation
ARIA -- Accessible Rich Internet Applications, cont.ARIA Roles: Define what an element is or does (i.e., role=“button” for buttons and role=“alert” for errors & alerts). This includes landmarks such as:
• Nav
• Main
• Search
ARIA States: Defines the state of an object (i.e., checked).
• Aria-disabled: Ensures AT is aware that the control is disabled• Aria-checked: Ensures AT is aware the control is checked
Reference: WebAIM Accessibility of Rich Internet Applications
{Code} Patterns
Accessibility 101 -- Basic HTML Patterns• Use headings – h1 through h6 for screen readers• Lang attribute: <html lang=“en”>• Layout should always have role=“presentation”• Don’t use floats for order• Alt text with images
Examples: http://plnkr.co/edit/mWKWcfm6z8gwQCuo0bJd?p=preview
Accessible ImagesAlt text:
• Provide meaningful alt text; this means that for a logo, provide more than just “logo” or the company name. You want to either describe what’s happening in the image, or describe the function that accompanies the image.
• Icons depend; if you click on the icon to take action, describe the action in alt text. Otherwise, leave an empty alt.
• Decorative images don’t need alt text (i.e., spacers, border images, etc)
Accessible Images, cont.Determining if alt text is needed:
1. The image is the only item in a link (i.e., logo to home page) or a form control (i.e., a radio button with an image as the selection)
2. The image includes text instead of text positioned on top of the image
3. The image adds meaning to the page (i.e., banner, photograph, graph or chart)
Accessible Images, cont.ASCII:
• Images created with text characters (i.e., Next > or Next > to escape HTML errors)
• Best to use images with alt text instead
Accessible Images, cont.Font Icons:
• Font icons (i.e., Glyphicons or Font Awesome) may be read as wrong symbol or an emoji
• For font icons, wrap in a span and hide it using aria-hidden. Include fallback text for screen readers only. [WebAIM Recommendation]
Examples: http://plnkr.co/edit/gSFy9prnH8uvaiOkpf5P?p=preview
VideoAt the bare minimum:
• Use the native video tag • Caveat: Firefox has an open defect since 2009 where the controls are
not accessible via keyboard• For addressing defects & quirks, use Paypal’s Accessible Video Player
• Don’t set autoplay
• Include transcripts and captions (which are synchronized w/ the spoken word & equivalent)• Closed captions: Can be toggled on and off• Open captions: On top of image and can’t be turned off
Video, Cont.• Audio descriptions utilized to provide additional info
about what’s being shown on the screen• Sign language interpretation running concurrently• 3 Flashes or Below Threshold -- 3 flashes per second or
below, esp of red light
Forms• Main concerns are ensuring that the form is:
• Readable by a screen reader
• Flows in a logical order
• Keyboard accessible
• Use a label with a ‘for’ attribute to tie it to the form control:• <label for=“first_name”>First name:</label> <input type=“text” id= “first_name”>
• May also need to include the ‘name’ attribute on the input tag
• Use a title attribute when you can’t use a label
• Use fieldset with legend for related controls (i.e., checkboxes or radio buttons)
Forms, cont.• Use type=“submit” on buttons associated with forms• Can enable keyboard shortcuts using the “accesskey”
attribute• <a href=“home.html” accesskey=“h”>Home</a>
• Use aria-live and/or aria-invalid for errors
Examples (& screen reader demo): http://plnkr.co/edit/FmI3ZFHTEKm0mDHMqdRI?p=preview
Tables• Include a caption in your tables
• Caption is like a title for the table
• Can include a summary in the caption tag (legacy)
• Summary attribute can also be used on the table tag
• Mark up table header, table body, table footer (if there is one)
• Properly scope your table columns and rows
• Try to keep columns and rows “flat”
Example: http://plnkr.co/edit/3QcYNMYnXpWaX3m765BS?p=preview
Dynamic ElementsLive Regions: According to the W3C, these are “perceivable regions of a web page that are typically updated as a result of an external event when user focus may be elsewhere.”
Dynamic Elements -- Error Messaging, Cont.Inline messaging example: Two ways to do it “properly”, according to The Paciello Group. The first way is to nest the error with an ID inside of the label of the field item:
<label id=“first_name_label” for=“first_name_input”>First name: <span id=“first_name_error”></span></label><input type=“text” id=“first_name_input”>
Dynamic Elements -- Error Messaging, Cont.Block messaging example: If you are using multiple labels (i.e., showing an error for two fields with two assoc labels), use this technique:
<label id=“name_error” for=“first_name_input”></label><label id=“first_name_label” for=“first_name_input”>First name:</label><input type=“text” id=“first_name_input” aria-labelledby=“first_name_label name_error”>
And set aria-invalid = true on the incorrect input
Dynamic Elements -- Error Messaging, Cont.Expanded Example: http://plnkr.co/edit/plDwy5aAFX5WGiAXLS2O?p=preview
Dynamic Elements -- Modal Windows• Focus trapped in the window until it is dismissed• Escape key for closing window (keyboard shortcut)• Modal HTML snippet should have aria-hidden=true until the
window is opened• Tabindex programmatically set in window when active• Tabindex -1 in HTML snippet before modal is activated• X buttons should have title assoc with it for “Close”
Reference: The Incredible Accessible Modal Window
Tools & Reference
s
Tools for Testing -- GeneralWAVE: Accessibility eval tool that embeds inline feedback in web content (demo)
• Check reading order for screen readers (removes styles)• Image – alt attr is displayed, alt text conveys useful info, images of
text• Headings – marked up correctly• Contrast – AA contrast issues, links for standing out as links (3:1
contrast)• HTML5 (regions) & ARIA (ensures correct landmarks, states, properties,
labels)• Forms – descriptive labels, programmatically tied labels and controls• Page language (lang=“en” )• Tables – table headers and they are scoped
Tools for Testing -- General, Cont.Keyboard Accessibility:
• Check that these keys work as expected:• Tab: Links & form controls• Shift + Tab: Navigate backwards• Enter: Activate links & buttons• Spacebar: Checkboxes and btns• Arrow keys: Radio btns, select/dropdowns, sliders, tab panels,
autocomplete, tree menus• Check for items that mouse-over only• Check for skip navigation link• Check that the navigation order makes sense• Check for visible keyboard focus
Tools for Testing, General, Cont.Content Scaling: (Test it at least at 200%)
• Safari: View > Zoom Text Only• Firefox: View > Zoom > Zoom Text Only• IE: View > Text Size
Tools for Testing Visual Impairment• Contrast checker (demo):
• Colour Contrast Analyser (has support for other languages)
• WebAIM Color Contrast Checker
• Screen Reader• Windows: JAWS or NVDA (open source) – download JAWS and double click
it to enable it
• MAC: VoiceOver – Apple Icon > System Preferences > Accessibility/Universal Access and then VoiceOver
• Color blindness (demo)• Color Scheme Designer 3
• Coblis Color Blind Simulator (images)
Further Resources -- ReadingReading:
• The Paciello Group
• Simply Accessible
• The A11y Project
• WebAIM
Further Resources -- ReferencesReferences:
• W3C WAI
• Web Content Accessibility Guidelines (WCAG) 2.0
• Core Accessibility API Mappings
Further Resources -- TestingTesting:
• WebAIM’s WCAG 2.0 Checklist
• Web Accessibility Toolbar (WAT)
• Accessibility Viewer (aViewer)
Q&AQuestions? Fire away!
