You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Accessibility in Mozilla

Aaron Leventhal

aaronleventhal@moonset.net

There is also a graphical version of the slide show.

What's Covered in this Talk

  1. Understanding accessibility
  2. Mapping the problem
    • Environments to support
    • Types of access to support
    • Analyze your UI
  3. Justifying the work
  4. Doing the work
  5. How's IBM Helping?
  6. Summary

Step 1. Understand Accessibility

  • When everyone can use & understand something
  • Software Accessibility: people w/ disabilities use software via alternate input & output methods.
  • Free & open source software (FOSS) advantages
    • Empower the community of engineers with disabilities
    • Universities, charitable org's, volunteers can contribute so we don't always need to wait for "business case"
    • Access to bug databases, design plans, engineers and daily builds is a big help for assistive technology vendors

Visual impairments & print disabilities

  • Blind and deaf-blind people use screen reading software
  • Partially sighted people (e.g. Aldous Huxley: low vision) may use font/contrast settings or screen magnification software.
  • Dyslexic people use text to speech software combined with word highlighting

Physical disabilities

  • Quadriplegics (e.g. Christopher Reeve) use the keyboard with a mouth stick, on screen keyboards, dwelling software, speech input software and head/eye tracking mice
  • One handed typists use sticky key software
  • People with Amyotrophic Lateral Sclerosis - ALS (Lou Gehrig's Disease) (e.g. Stephen Hawking) or cerebral palsy may use filter keys, word prediction software and single switch devices

Other disabilities

  • Hearing impaired people need software that do not rely on sound for cues
  • Color blind people need software that does not rely on color alone: 8-10% of males see both red and green as brown!
  • Persons with cognitive and learning disabilities need software with simple layout and messages; also useful for young, elderly and newbie users
  • Persons with epilepsy (e.g. Nobel) need software with no flashing or blinking: 2-55 Hz can cause seizures (Mozilla does this right)

Software Assumptions

That users can:

  • Read and react to text and images
  • Type on a standard keyboard
  • Point & click on text, images & widgets
  • Hear and react to sounds played

What about users with blindness, deafness, color blindness, low vision, obstructed vision, tunnel vision, dyslexia, dyspraxia cognitive disability, autism, Asperger's syndrome, amputation, paralysis, cerebral palsy, repetitive stress, muscular dystrophy, multiple sclerosis, Parkinson's?

Factor in aging baby boomers, that's a lot of users!

The Curb Cut Effect

Accessibility helps everyone

Curb cuts are also used for bicycles, luggage, shopping carts, strollers, ... "Mainstream" inventions often start out as assistive technologies: typewriter, condenser microphone, tape recorder, email, Optical Character Recognition (OCR), speech synthesis, speech recognition, closed captioning, pager ... Read the excellent article The Electronic Curb-Cut Effect: Disability and Development by Steve Jacobs at The International Center for Disability Resources on the Internet (ICDRI)

Step 2. Mapping the Problem

  • What platforms / operating systems?
  • What assistive technologies?
  • What 3rd party applications?
  • What API's?
  • What's missing?

Accessible Platforms

Assistive Technology I - OS Themes & Screen Magnifiers

Magnifiers (3rd party software): ZoomText, MAGic, gnome-mag, kmag

  • 1.5 - 2.5x: theme / font size changes ok
  • 3x - 5x: screen magnification needed
  • 5x+: text to speech or braille display (move to screen reading software)

Magnification is simpler than screen reading software: track the focus and the caret and keep them on the screen at all times.

Assistive Technology II - Text to speech & Braille Displays

Screen readers (3rd party software): JAWS, Window-Eyes, Gnopernicus, Orca

Very hard: a matter of transforming information from a visual, random-access medium to a sequential medium

Assistive Technology III

Input aids via keyboard API - sometimes built-in to OS

  • Sticky keys, for one handed typing
  • Filter keys, fewer accidental keystrokes
  • Voice input, useful for everyone
  • Mouse gestures, useful for everyone,
  • GOK / on screen keyboards, pointer to key translation
  • Mouse keys, key to mouse translation
  • Keyboard macros, useful for everyone
  • Custom keyboards, also a popular learning tool
  • Single switch devices, Stephen Hawking uses this
  • Word prediction, cell phones now have this!

Assistive Technology IV - Voice Input

Dragon Naturally Speaking is the leader (3rd party software)

  • Say What You See feature
  • Most complete voice input solution for disabled users. Can fully replace mouse use!
  • Scripting & Macros required for best experience

Assistive Technology V - Video Access

  • Closed captioning. Real-time text version - great for bar & airport patrons!
  • Audio description. Real-time audio of what's otherwise only visual. Uses Second Audio Program (SAP) on your TV

Accessibility Challenge! What's not accessible here?

Image of simple dialog with traffic light for mail send status

The Context Problem

  • What should be spoken the mail send status?
  • What should show on the Braille display?
  • What if the same image means something else in another application?

The Context Solution

  • UI designers provide a text equivalent for all informational & interactive objects that don't have text (non eye-candy)
  • Developers set the text using title=string attribute
  • QA Engineers test UI with a screen reader, to ensure all information is spoken

How Many Accessibility Problems?

Screen shot of older version of Mozilla calendar app, with some extra accessibility problems added

Calendar Challenge Answers

  • Tab order too big, need [shift]+F6 tab by pane
  • Check for View -> Sort by. Which list does it sort?
  • What does strikethru or red indicate?
  • How does one move selection in grid?
  • How to do multiple selection in grid?
  • Interface too complex for many users
  • What do the checkboxes mean?
  • Must show focus vs. selection
  • How to toggle checkboxes?
  • Right click = shift+f10
  • Enter key = double click
  • Drag and drop required?
  • Missing mnemonics
  • How to collapse panes?
  • Small targets

Step 3. Justify Resources

  • Scope out the work, triple it
  • Explain the problem
  • Justify business case:
    • show actual sales at stake
    • document legal exposure
    • get other depts involved
  • Very difficult to get resources: companies don't want to pay for a11y

Eval Process, how state $ are spent

Uh oh - when you lose an ability (most people not disabled from birth)

California as an example:

  • Doctor refers you to State Dept. of Rehabilitation
  • Assigned an eval specialist to check abilities/needs/setup
  • If you're already running FOSS you can get money to switch to Win/MS Office/IE
  • German system uses a pool of resources, works really well

Government Procurement

  • U.S. Gov't as example
  • Start w/ list of Section 508 compliant software (need Voluntary Product Accessibility Template (VPAT) showing compliance) or must prove no alternatives
  • All parties cautious of legal liabilities
  • Want to use FOSS because of cost, security and other issues, but most not 508 compliant
  • New EU rules stricter than 508, based on W3C
  • A11y best way to get 100k+ desktops

Step 4. Do The Work

  • Lots of bugs everywhere
  • Fix deep bugs first in widgets, layout, DOM
  • Fix shallow bugs next in the front end
  • Front end bugs are often fixed by core fixes. Try to fix everything in the general way.
  • Patience and stamina are key

Coding Techniques - Estimate of Effort

  • 101. Keyboard: 25%
  • 102. Focus and Tabbing: 20%
  • 103. Themes: 10%
  • 104. MSAA/ ATK: 30%
  • 105. Test and Polish: 15%

Techniques 101: The Keyboard

  • Keyboard API is reused by all kinds of tech.
  • Everything must have keyboard equivalent, otherwise the feature is unusable for lots of people
  • Mnemonics: underlined chars in labels via accesskey
  • Support menu and other accelerators with <keyset>, <key> and key="keyname" attribute
  • Support context menu key via oncontextmenu
  • Consistency - use desktop keyboard reference

Techniques 102: Tabbing & Focus

  • Always clearly visible, usually via blah:focus {outline: 1px dotted invert;}
  • Moves thru all interactive elements, if necessary ordered via tabindex attribute
  • Consistent when going forward or back
  • Not lost if destroyed, hidden, collapsed or disabled

Techniques 103: OS Theme Compatibility

  • OS's provide high contrast themes
  • On Win you can toggle it with Left Alt + Left Shift + Print Screen
  • Mozilla detects it & forces classic skin
  • Misnomer: high contrast refers to any forced color & font setting, even low contrast
  • Don't use hard coded color or size values or you will break accessible themes!

Techniques 104: Providing Context

What Microsoft Active Accessibility (MSAA) & Accessibility Toolkit (ATK) provide

  • Who: The name is a speakable string name for this object.
  • What: The role is an enumerated constant exposing what object is (60+ roles - button, slider, etc.)
  • Where: The bounds are the x, y, width and height for a control.
  • When: Events are used to notify the assistive technology when the current object has received focus, or has had a name or state change.
  • State: A 32-bit wide field of boolean values, such as checked, focused, hidden, disabled, expanded

Techniques 105: Test & Polish

Screen reader users are great testers

  • Push keyboard to limits
  • Find focus issues
  • Find what's not exposed, or exposed incorrectly
  • Toughest to please, but get you 80% there

Variety of end-user types is important

Crafting Accessible XUL

  1. Don't break the tab order:
    • all interactive elements & docs need to be in tab order
    • the tab order should usually go from left to right, then top to bottom
  2. Don't rely on toolbar buttons. Toolbar butons aren't members of the tab navigation cycle or menus.
  3. Ensure sensible focus behavior. Focus should never get lost when a focused item is disabled, hidden or destroyed.
  4. Support accesskeys (mnemonics) on interactive UI widgets. See the XUL accesskey FAQ.
  5. Use the tooltiptext attribute on all informative or interactive images (such as buttons), so that they're spoken by screen readers run by blind users.
  6. Don't require fast responses (physical reactions, decision making or comprehension) from the user.
  7. Ensure full keyboard access. Try to use w/ keyboard. Does it require a mouse (e.g. drag and drop)? Is it only visual/random access, or also sequential?
  8. Watch out for mouse event code. That's a red flag.
  9. Context menus must support the keyboard, via oncontextmenu -- don't handle the right click directly.
  10. Don't rely on color alone to present info.
  11. Avoid small targets which are difficult to see and click on.
  12. Try to avoid scroll bars in XUL.
  13. Sortable tree views need a View -> Sort by menu.
  14. Use the label element or attribute to add text labels. Otherwise you're requiring screen readers to guess.
  15. Every control must have a text label.
  16. Ensure the Escape key cancels dialogs and closes them without changes, like Cancel
  17. Ensure a default button in dialogs via <button default="true">
  18. For new shortcut keys, consult the keyboard shortcuts list & talk to me - aaronleventhal@moonset.net
  19. For new widgets (e.g. XBL), consult me
  20. Think about many kinds of users

Mozilla A11Y - IBM Involvement

  • Seamonkey browser work slowing down
  • Firefox 1.5 access work starting 2004 Q3
  • Provide DHTML accessibility solution
  • Push EU to adopt sensible JS a11y standards
  • New formats: XUL 2.0, Web Forms, X Forms
  • Windows AT's: ZoomText, Window-Eyes
  • Still planning Linux screen reader strategy

IBM's Mozilla A11y Gap Analysis:

  • Required: IBM Strategy
  • Keyboard support: Fix Seamonkey sidebar and plugins keyboard support
  • Fix Firefox keyboard accessibility
  • Windows AT support: Window-Eyes, ZoomText alpha support, keyboard tools
  • Linux AT support: Gnome Onscreen Keyboard (GOK) + keyboard tools
  • Need hardware-accelerated magnification in X Windows Gnopernicus has issues, we may go different route
  • Testing & tools: AT Poke needs work. Need to build up test cases
  • Rich access (level 2): Direct access to nsIAccessible APIs, work on freezing
  • Fast, clear, i18n TTS engine on Linux: ViaVoice text to speech engine
  • distributed through Wizzard Software
  • Javascript / DHTML: W3C Dynamic Web Content Taskforce
  • New formats: Web Forms, X Forms
  • IBM's not supporting: (Mozilla community involvement needed): Thunderbird, Nvu, most extensions, web dev tools, SVG (yet), MathML, Dragon Naturally Speaking support

When are you finished?

  • When the negative feedback loop becomes a positive feedback loop.
  • When there is a critical mass of users with disabilities

Summary: Motivations

  • Pride & Principle
  • Professional design
  • P.R. & Prestige
  • Self Preservation
  • Personal Profit a11y skills in demand
  • Corporate Profit & Desktop Presence The way to displace MS in Government!
  • Protection against legal challenges
  • Productivity through keyboard

Lost? Accept Guidance

  • Search source code with LXR & docs or Google for the answer
  • UI issues: see how MS does it. They often get a11y right :/
  • Feel free to contact the community
  • Use Newsgroups
  • Read accessibility resource sites

Resources