Mozilla’s UAAG evaluation report

The UAAG document contains a very rich set of accessibility guidelines, that broadly define how accessibility should be implemented by any user agent, i.e. software that renders web content. The UAAG is not the basis for any government accessibility regulations at this time.

This document is based on the September 12, 2001 Candidate Recommendation of UAAG 1.0. This may be different from the most recent version, check for updates on the User Agent Working Group home page. Look to the "techniques" document for real-world implementation examples of each checkpoint.

This UAAG evaluation report covers nightly builds of the Mozilla web browser itself, running on Windows 2000, as of February 20, 2002. We are claiming to support HTML 4, CSS 2, PNG, JPG and GIF. This evaluation does not cover Mailnews or Composer.

There may be accessibility and customizability features not listed here. A very good resource is The Customizing Document.

When filing Mozilla bugs based on UAAG requirements, please use bug 24413 as the UAAG meta bug.

Checkpoint Information

(Same scaled used on W3C's UAAG implementation reports pages)

Rating Scale
C: Complete Implementation
VG: Very Good Implementation, almost all requirements satisfied
G: Good Implementation, most important requirements satisfied
P: Poor Implementation, some requirements satisfied and/or difficult for user to access feature
NI: Not Implemented
NR: Not Rated
NA: Not Applicable

Document under construction

Guideline 1. Support input and output device-independence.
Checkpoint Title Status Notes/plans
1.1 Full keyboard access. (P1) VG We have some remaining bugs, and some keyboard usability issues, but in general Mozilla now has keyboard equivalents for almost everything.
Most browsers do not allow the user to select text with the keyboard alone. We intend to do this with a caret browsing feature.
1.2 Activate event handlers. (P1) P onMouseOver, onMouseDown, onMouseUp, onMouseMove, onClick, onDBClick: no keyboard support
onFocus and onBlur: Cannot be activated with pointer
1.3 Provide text messages. (P1) C Status line and alert boxes used to convey messages and alerts
Guideline 2. Ensure user access to all content.
Checkpoint Title Status Notes/plans
Checkpoint Title Status Notes/plans
2.1 Render content according to specification. (P1) VG Renders HTML, CSS, and a number of graphic image formats. Does not contradict current specifications for HTML and CSS rendering.
2.2 Provide text view. (P1) C Also known as view source.
2.3 Render conditional content. (P1) VG ALT for IMG: rendered when images turned off. See meta bug 41924 for open issues with the ALT attribute.
TITLE for *any* element: rendered as tooltip
LONGDESC for IMG element: in context menu - properties
content of OBJECT element: ?
ALT for AREA element: ?
ALT for INPUT element: ?
ACRONYM element: supported
ABBR element: supported
ABBR attribute for TD/TH: not supported
SUMMARY for TABLE: supported
TITLE for FRAME: ?
LONGDESC for FRAME: Not supported, see Bug 3658
NOFRAME for FRAME: Must use user style sheets to render this. A UI for this would be good.
NOSCRIPT for SCRIPT: Must use user style sheets to render this. A UI for this would be good.
2.4 Allow time-independent interaction. (P1) NR Need to look into this
2.5 Make captions, transcripts available. (P1) NA This relates to multimedia players
2.6 Respect synchronization cues. (P1) NA This relates to multimedia players
2.7 Repair missing content. (P2) P No ALT repair strategies in place.
Reasons: The title attribute is almost never present when the alt isn't. In the rare cases where it is, it is of no help (typically it's just the filename, maybe with a file size). Also, in the overwhelming majority of cases, the filename is unintelligible. Developers interested in this problem can look at the GetAlternateText() method -- see the CVS history for suggestions. We consider this to be a very difficult problem.
2.8 No repair text. (P3) P We have no repair strategy in 2.7
We have no way to configure that alt="" still needs to be repaired
2.9 Render conditional content automatically. (P3) G ALT for IMG: rendered when images turned off
TITLE for *any* element: rendered as tooltip
LONGDESC for IMG element: in context menu - properties
content of OBJECT element: ?
ALT for AREA element: ?
ALT for INPUT element: ?
ACRONYM element: supported
ABBR element: supported
ABBR attribute for TD/TH: not supported
SUMMARY for TABLE: supported
TITLE for FRAME: ?
LONGDESC for FRAME: Not supported, see Bug 3658
NOFRAME for FRAME: Must use user style sheets to render this. A UI for this would be good.
NOSCRIPT for SCRIPT: Must use user style sheets to render this. A UI for this would be good.
2.10 Toggle placeholders. (P3) NI  
2.11 Alert unsupported language. (P3) NR ?
Guideline 3. Allow configuration not to render some content that may reduce accessibility.
Checkpoint Title Status Notes/plans
3.1 Toggle background images. (P1) C Preferences, Appearance, Colors - "Use my chosen colors, ignoring the colors and background image specified"
3.2 Toggle audio, video, animated images. (P1) P Animated images can be made still with the Escape key
Animated images can be made still as a preference under Preferences, Privacy & Security, Images - "Animated Images should Loop"
Mozilla has no preference or command to toggle audio or video
3.3 Toggle animated/blinking text. (P1) P The following line can be added to a user's prefs.js file to control blinking:
user_pref("browser.blink_allowed", false);
Bug 89144 has been filed to expose this pref in the UI.
Mozilla doesn't support <marquee> by default.
3.4 Toggle scripts. (P1) G Preferences, Advanced, Scripts & Windows - Enable Javascript For
When toggled off, we don't notify the user when a page is loaded with scripts
3.5 Toggle content refresh. (P1) NI Mozilla has no features for toggling refreshes
3.6 Toggle redirects. (P2) NI Mozilla has no features for toggling redirects
3.7 Toggle images. (P2) P Our interface for image toggling needs redesign
Unfortunately, there are quite a few open bugs on image toggling
Guideline 4. Ensure user control of rendering.
Checkpoint Title Status Notes/plans
Checkpoint Title Status Notes/plans
4.1 Configure text size. (P1) C Can be changed through preferences, zooming or user style sheet. Zooming is really the best solution, because the document retains its look - all font sizes are increased the same percentage.
Zooming can be controlled via hotkeys Ctrl+plus and Ctrl+minus
The prefs are at Preferences, Appearances, Fonts
There is also a hidden pref line that can be added to prefs.js, if you just want to change the minimum font size for a certain font:
user_pref("font.minimum-size.x-western", newFontSizeInPoints);
For other i18n charsets, change x-western to x-central-euro, x-cyrillic, x-unicode, x-user-def, x-baltic, el, tr, he, ar, th, ja, zh-CN or zh-TW
4.2 Configure font family. (P1) C Can be changed through preferences or user style sheet
The prefs are at Preferences, Appearances, Fonts
4.3 Configure text colors. (P1) VG Can be changed through preferences or by editing the prefs.js file
The prefs are at Preferences, Appearances, Colors
To use any color offered in Windows, the prefs.js file must be edited by hand
4.4 Slow multimedia. (P1) NI Cannot slow animations
4.5 Start, stop, pause, and navigate multimedia. (P1) NA  
4.6 Position captions. (P1) NA  
4.7 Slow other multimedia. (P2) NA This is similar to checkpoint 4.4, except that includes animation through style
Cannot control animation rate of animated images
4.8 Control other multimedia. (P2) NA  
4.9 Global volume control. (P1) NA  
4.10 Independent volume control. (P1) NA  
4.11 Control other volume. (P2) NA  
4.12 Configure synthesized speech rate. (P1) NA  
4.13 Configure synthesized speech volume. (P1) NA  
4.14 Configure synthesized speech characteristics. (P1) NA  
4.15 Specific synthesized speech characteristics. (P2) NA  
4.16 Configure synthesized speech features. (P2) NA  
4.17 Choose style sheets. (P1) C Under View Menu, Use Style Sheet -- allows one user style sheet to be applied at a time
Guideline 5. Ensure user control of user interface behavior.
Checkpoint Title Status Notes/plans
5.1 No automatic content focus change. (P2) C Preferences, Advanced, Scripts & Windows - Allow Scripts To "Open Unrequested Windows"
5.2 Keep viewport on top. (P2) C Windows can be configured so that the window with the current focus is always on top.
5.3 Manual viewport open only. (P2) VG Preferences, Advanced, Scripts & Windows - Allow Scripts To "Open Unrequested Windows"
We do not have a strategy to "alert the user and allow the user to open it on demand"
We do not have exposed prefs for all of our popup control options.

Here are all the "hidden prefs" lines that can be added to the user's prefs.js file, for controlling popup behavior:
  • Turn window.open off for particular sites:
    user_pref("capability.policy.popupsites.sites", "http://www.annoyingsite1.com http://www.popupsite2.com");
    user_pref("capability.policy.popupsites.windowinternal.open", "noAccess");
  • Or turn it off everywhere:
    user_pref("capability.policy.default.windowinternal.open", "noAccess");
  • Override popping up new windows on target=anything:
    user_pref("browser.target_new_blocked", true);
  • Override popup windows at beginning of new page load (blocks most popup advertisements):
    user_pref("dom.disable_open_during_load", true);
5.4 Selection and focus in viewport. (P2) C When focus and/or selection changes they are in the viewport
5.5 Confirm form submission. (P2) P Only allows confirmation if the information is not secure?
This is also under Preferences, Security, SSL, "Sending form data from unencrypted page to unencrypted page"
5.6 Confirm fee links. (P2) NI No support of fee links
5.7 Manual viewport close only. (P3) C Just fixed! See Bug 32571 for more information.
Guideline 6. Implement interoperable application programming interfaces.
Checkpoint Title Status Notes/plans
6.1 DOM read access. (P1) VG The DOM is available in-process, but not via an out-of-process (COM) interface.
Out-of-process access is needed for it to be truly useful for assistive technology
We do support some COM interfaces called ISimpleDOMNode, which has a large portion of useful DOM read access
6.2 DOM write access. (P1) G The DOM is available in-process, but not via an out-of-process (COM) interface.
Out-of-process access is needed for it to be truly useful for assistive technology
We do support some COM interfaces called ISimpleDOMNode, which has a large portion of useful DOM read access
6.3 Programmatic access to non-HTML/XML content. (P1) NI Still working on Active Accessibility support for other kinds of content
6.4 Programmatic operation. (P1) VG Can use keyboard API to control Mozilla, by generating keystrokes programmatically
When in-process, can use DOM to generate events
Uses Active Accessibility to provide program access to controls
Do not support all Active Accessibility features for programmatic operation (put_accName, put_accValue not yet supported)
6.5 Programmatic alert of changes. (P1) G Uses Active Accessibility to generate change events to assistive technology
6.6 Conventional keyboard APIs. (P1) C Uses standard keyboard API, works with a number of assistive technologies
6.7 API character encodings. (P1) ? We use 16 bit strings, not sure about UTF-16
6.8 DOM CSS access. (P2) G The DOM is available in-process, but not via an out-of-process (COM) interface.
Out-of-process access is needed for it to be truly useful for assistive technology
6.9 Timely access. (P2) NR Too vague to measure.
Rating Scale
C: Complete Implementation
VG: Very Good Implementation, almost all requirements satisfied
G: Good Implementation, most important requirements satisfied
P: Poor Implementation, some requirements satisfied and/or difficult for user to access feature
NI: Not Implemented
NR: Not Rated
NA: Not Applicable
Guideline 7. Observe operating environment conventions.
Checkpoint Title Status Notes/plans
7.1 Focus and selection conventions. (P1) VG Mozilla uses selection colors as specified in the control panel.
Mozilla exposes the focus via WM_FOCUS system messages
Mozilla does not use the system focus drawing routines, because they aren't flexible enough (don't support CSS)
7.2 Respect input configuration conventions. (P1) VG Mozilla implements standard keyboard bindings
There are a few missing pieces, such as support in XUL comboboxes (menulist) for selecting items by typing alphanumeric keystrokes
7.3 Operating environment conventions. (P2) G Mozilla uses non-native controls. It does, however, support the look and feel of widgets on various operating systems, when the classic theme is selected (on by default).
7.4 Input configuration indications. (P2) G Menus indicate accesskey and accelerator configurations
Accelerators not show in button tooltips
Guideline 8. Implement specifications that benefit accessibility.
Checkpoint Title Status Notes/plans
8.1 Implement accessibility features. (P1) VG HTML: CAPTION element (TABLE): Renders in graphical interpretation, can be styled using CSS
HTML: THEAD element (TABLE): Available through DOM, can be styled using CSS?
HTML: TBODY element (TABLE): Available through DOM, can be styled using CSS?
HTML: TFOOT element (TABLE): Available through DOM, can be styled using CSS?
HTML: COLGROUP element (TABLE): Available through DOM, can be styled using CSS?
HTML: COL element (TABLE): Available through DOM, can be styled using CSS?
HTML: SCOPE attribute (TABLE): Available through DOM
HTML: HEADERS attribute (TABLE): Available through DOM
HTML: AXIS attribute (TABLE): Available through DOM
HTML: TABINDEX attribute: yes, can be used to order sequential navigation
HTML: ACCESSKEY attribute: Supported with ALT-{key}, menu key conflict favor the accesskey?
HTML: ALT for IMG: yes
HTML: LONGDESC for IMG: yes, available in context menu properties
HTML: ALT for AREA: ?
HTML: ALT for INPUT: ?
CSS: TEXT-INDENT: yes
CSS: TEXT-ALIGN: yes
CSS: WORD-SPACING: yes
CSS: LETTER-SPACING: yes
CSS: FONT-STRETCH: NI
CSS: MARGIN: yes
CSS: FLOAT: yes
CSS: POSITION: yes
CSS: !IMPORTANT: yes
CSS: SYSTEM FONTS: yes
CSS: SYSTEM COLORS: yes
CSS: list types: yes
CSS: OUTLINE: no
CSS: :before, :after, content: P(oor)
8.2 Conform to specifications. (P2) VG HTML 4.01: VG
CSS 1: VG
CSS 2: VG
DOM 1.0: VG
Guideline 9. Provide navigation mechanisms.
Checkpoint Title Status Notes/plans
9.1 Provide content focus. (P1) C Provides a content focus
9.2 Provide user interface focus. (P1) C Provides a user interface focus
9.3 Move content focus. (P1) G Provides sequential access to links and input form controls
Cannot navigate to non-links and non-input form controls with event handlers
Cannot configure Mozilla to only allow focus changes on explicit user request
9.4 Restore history. (P1) NI See bug 36539
9.5 No events on focus change. (P2) P Can turn off scripting, but then no event processing is available
9.6 Show event handlers. (P2) P Can view event handlers through source view or DOM Inspector (Tasks, Tools, DOM Inspector)
9.7 Move content focus optimally. (P2) G Provides sequential access to links and input form controls
Cannot navigate to non-links and non-input form controls with event handlers
No directional navigation, or navigation to links by name
9.8 Text search. (P2) VG Provides forward and reverse text search capability from the element with the current focus/selection, with and without case sensitivity
Very slow on larger documents. Needs improvement.
9.9 Structured navigation. (P2) P DOM Inspector provides some capability, but not really intended for end users (Tasks, Tools, DOM Inspector)
9.10 Configure important elements. (P3) NI The navigational elements aren't user configurable
Guideline 10. Orient the user.
Checkpoint Title Status Notes/plans
Checkpoint Title Status Notes/plans
10.1 Table orientation. (P1) NI We don't make use of scope, headers, axis, or any other table accessibility features
We have nothing under properties, or anywhere else, to orient users reading a table
10.2 Highlight selection and content focus. (P1) VG Provides a focus outline box
Highlights follow graphical rendering conventions for windows
Does not highlight selected images
We do not have the ability to show a border around the text selection
We have the following focus appearance prefs that are not exposed in the UI, but can be manually inserted in the user's prefs.js file:
SetBoolPref("browser.display.use_focus_colors", useFocusColors); /* true or false */
SetCharPref("browser.display.focus_background_color", colorString); /* for example #ffeedd or the name of a color */
SetCharPref("browser.display.focus_text_color", colorString);
SetCharPref("browser.display.focus_ring_width", numPixels); /* integer 0-4 */
10.3 Distinct default highlight styles. (P1) VG We rely on color alone when showing which links have been recently visited. Should implement a pref for dotted underline on visited links, similar to the way Opera does it.
10.4 Highlight special elements. (P2) G Use system colors by default (classic theme)
Underlines links by default
Does not have UI to highlight non-link and non-form elements that have event handlers
Can have user CSS for user styling of elements with event handlers
10.5 Outline view. (P2) P DOM Inspector provides a type of outline view, although it is not intended for end users
Page info (Ctrl+I) gives lists of links, media, forms/elements
Can use a user style sheet to implement an outline
Bug 127030 has been filed for an outline view.
10.6 Provide link information. (P3) G Only uses color to indicate whether a link has been visted by default

Context menu properties provides link information, but does not provide the size of the resource. Note that the size might be discovered for certain resources using HTTP HEAD. However, any such use should be carefully considered, given the potential impact on network traffic of automatically making such requests for every link/object in the page. Please see bug 103704 for more information.

Does not provide information about whether link is internal or external, except through URL itself. Clearly identifying internal vs. external links is bug 127038.

Provides information about whether link will open in same window

Does not support fee links

10.7 Highlight current viewport. (P1) VG Uses title bar color and focus indicator to indicate with view port has focus
The currently focused content frame has a dotted outline, until a key is pressed or scrolling occurs
The focus appearance is not configurable
10.8 Indicate rendering progress. (P3) VG

A progress bar and status bar message indicates loading progress

The scroll bar indicates how far into the document the current graphical view is

The size of the current document is in the page info screen, sometimes it says unavailable

Guideline 11. Allow configuration and customization.
Checkpoint Title Status Notes/plans
11.1 Current user bindings. (P1) G

Menus indicate accesskey and accelerator configurations

Accelerators not show in button tooltips

No centralized key bindings informational resource for end-users, only developer documentation

11.2 Current author bindings. (P2) NI The web page itself is currently responsible for letting the user know what accesskey's are available.
11.3 Override bindings. (P2) P

Some bindings can be changed. See "the customizing document"

There is no central place to change all bindings. Unforutunately, some are hard coded. Needs work. Bug#?

11.4 Single key access. (P2) NI Bug 953707 is our open bug for this. Help wanted.
11.5 Default binding requirements. (P2) C Provides stated functions
11.6 User profiles. (P2) VG

User profiles are fully supported for all configuration options.

Unfortunately, switching profiles requires the entire application to be relaunched.

There is still very little end-user documentation for editing profiles by hand.

11.7 Configure tool bars. (P3) P

Can turn on and off toolbars under Show/Hide

Can customize personal bookmarks toolbar

Bug 15144 is for the ability to add/remove toolbar icons
Bug 47418 is for the ability to rearrange toolbars

Guideline 12. Provide accessible user agent documentation and help.
Checkpoint Title Status Notes/plans
12.1 Accessible documentation. (P1) NR

Some end user docs are under Help, Help Contents in Mozilla

Here is the main page for Mozilla end user documentation

None of these resources have been evaluated for WCAG compliance

12.2 Document accessibility features. (P1) NI No end user accessibility documentation yet
12.3 Document default bindings. (P1) NI No end user accessibility documentation yet
12.4 Document changes. (P2) NI No end user accessibility documentation yet
12.5 Dedicated section on accessibility. (P2) NI No end user accessibility documentation yet
Rating Scale
C: Complete Implementation
VG: Very Good Implementation, almost all requirements satisfied
G: Good Implementation, most important requirements satisfied
P: Poor Implementation, some requirements satisfied and/or difficult for user to access feature
NI: Not Implemented
NR: Not Rated
NA: Not Applicable

 

Document Tags and Contributors

 Contributors to this page: Sheppy, StevenGarrity
 Last updated by: Sheppy,