Current browsers and the User Agent Accessibility Guidelines 1.0
A personal reflection / opinion piece by Patrick H. Lauke, with input from the Accessibility Task Force (reflecting the current state of browsers at the time of publication, 20 May 2007).
In web accessibility, you’ll often hear emphasis being placed on the duty of web authors to create accessible content. However, this is only one part of the web accessibility equation.
One that has been particularly close to me, or rather one that has provided me with a lot of opportunity to rant, is the responsibility of developers of user agents.
Any effort on the part of web authors to add accessibility features is rendered useless if browsers and assistive technologies don’t take advantage of them. User agent developers need to ensure that their products support these features and, most crucially, make them available to users in an accessible and obvious manner.
Although far from perfect, the W3C’s User Agent Accessibility Guidelines (UAAG) 1.0 do provide a good starting point.
What follows is a quick run-down of most of UAAG’s guidelines and checkpoints, annotated with comments, suggestions, personal gripes about current levels of implementation, and wishlists for future browser versions.
Admittedly a tad rough around the edges, this is a first attempt at crystallising some of the discussions I’ve had with fellow ATF colleagues, members from the W3C, and other accessibility aficionados.
It’s worth noting that in some places the article suggests that responsibility for satisfying a certain guideline/checkpoint falls to a particular plug-in, rather than the browser itself. Of course, plug-ins themselves (as they can be counted as “user agents” in their own right, in many cases) would need to comply with other parts of UAAG as well. For this article, however, we’re just looking at browsers themselves.
Guideline 1. Support input and output device-independence
Ensure that the user can interact with the user agent (and the content it renders) through different input and output devices.
1.1 Full keyboard access (P1)
Currently, it is not possible to set the focus on arbitrary elements in a document. For instance, a user cannot focus on an image and activate the browser’s context menu (to view the image separately, save it, etc). Even if an image is wrapped in a link, which can receive focus, the context menu presented to the user only offers options related to the link, not the image.
Adding any arbitrary element in the normal tab cycle would obviously make navigation in general rather cumbersome (though this could be made user configurable … see comments relating to 9.9). Firefox’s caret browsing, moving the cursor along the content of the webpage and responding to SELECT+ARROW commands, is a good step in the right direction. It also provides the only way for keyboard users to selectively copy/paste content from a web page, rather than having to grab all of the page’s content and taking out the part they’re interested in a separate (text editor) application. However, this caret browsing approach does not appear to be available in other browsers, such as Internet Explorer or Opera.
1.2 Activate event handlers (P1)
Allowing activation of click event handlers via keyboard has become de-facto standard in all modern browsers.
Although rarely used, it is currently not possible to trigger dblclick via the keyboard. This would probably best be handled by a key combination or modifier key, rather than requiring the user to hit the normal activation key twice in quick succession.
mousemove is, quite obviously, not triggered via the keyboard – although perhaps checkpoint 9.6 could address this.
Guideline 2. Ensure user access to all content
Ensure that users have access to all content, notably conditional content that may have been provided to meet the requirements of the Web Content Accessibility Guidelines 1.0
2.1 Render content according to specification (P1)
An age-old gripe: proper support for OBJECT elements, to be used for things such as Flash movies. This may be an issue related to the Flash plug-in architecture itself, rather than just the browser… but even if this requires close collaboration between plug-in and browser developers, it’s certainly something that should be addressed.
If “content” can also be extended to cover things like META information and LINK elements, these should be natively exposed to all users (possibly in a separate dialog box or toolbar). This already happens in many browsers in a “Page info” dialog, but these dialogs often don’t actually let users do anything meaningful with that information (such as activating/following a LINK’s URL).
2.2 Provide text view (P1)
The standard “view source” should satisfy this checkpoint.
2.3 Render conditional content (P1)
Browsers offer certain basic mechanisms (mainly for images) that render conditional content if the original resource is unavailable or its display has been disabled via the preferences.
Where multiple alternatives to conditional content exist, there is no mechanism to switch between them, and once content has been rendered, it’s not possible to show conditional content on the fly.
Also, because of the problem outlined in 1.1, it’s impossible to focus on an image by keyboard alone and choose to view any referenced longdesc alternative – combined with the fact that longdesc information isn’t natively provided by browsers anyway (without assistive technology or add-ons like the firefox longdesc extension ).
Taking it further, it’s not possible to focus on arbitrary elements to get things like title (if we treat this as conditional content as well). title is not exposed to keyboard users, and this seriously hampers keyboard user access to ABBR, ACRONYM, etc. or situations in which title attributes are tied to things like like form elements, links, etc.
2.4 Allow time-independent interaction (P1)
Browser should provide an option (on the fly or in the preferences) to stop any timed changes (such as META refresh/redirect and javascript activity which is not the direct result of a user interaction – a feature that will be implemented in the upcoming Firefox 3).
2.5 Make captions, transcripts, audio descriptions available (P1), 2.6 Respect synchronization cues (P1)
This should potentially be handled by multimedia plug-ins.
2.7 Repair missing content (P2)
If no conditional content is provided, an identifier (image, object, Quicktime object, etc.) and filename of the resource in question should be shown when the resource is unavailable or has been disabled in the preferences as per 2.3. This already happens for images (at least the “identifier” part, though some screen readers do report filenames or, in the case of linked images, the URL of the target), but not for other content types.
2.8 No repair text (P3)
There should be a user option in the preferences to suppress behaviour outlined in 2.7
2.9 Render conditional content automatically (P3)
Browsers provide preference settings for not loading images and rendering their conditional content instead. This functionality seems to be missing for other types of content (flash movies, java applets, etc).
It may also be advantageous to have an option in the preferences to automatically expand elements like ABBR and ACRONYM (with settings such as “Do not expand”, “Expand at first occurrence”, “Always expand”).
2.10 Don’t render text in unsupported writing systems (P3)
An interesting one… this could be handled by a preference setting “don’t display text in unsupported language” (“language” being a crude approximation for “writing systems” that users may be more familiar with). Ideally, when this option is enabled and the user gets to a page with unsupported text, this should be coupled with some sort of warning/notice similar to that generated by current pop-up blockers (“Text in an unsupported language has been removed from this page”).
Guideline 3. Allow configuration not to render some content that may reduce accessibility
Ensure that the user may turn off rendering of content (e.g., audio, video, scripts) that may reduce accessibility by obscuring other content or disorienting the user.
3.1 Toggle background images (P1)
Although guidelines state that browsers may satisfy this by disabling all images, a more targeted option in the preferences which strips out background images only (from markup and CSS, which the guidelines also hint at) would be far more useful.
3.2 Toggle audio, video, animated images (P1)
Similar in many ways to an explicit implementation of EOLAS patent requirements. Suppress autostart of multimedia, and possibly don’t even load audio/video/plug-in unless explicitly requested by user (“there’s a movie here… click to load and play”). This could be controlled by an option in the preferences. For animated GIF/MNG files, it could show the first frame but offer a cue that it’s an animation that can be started.
3.3 Toggle animated or blinking text (P1)
Option to automatically suppress blinking (BLINK element and text-decoration: blink in CSS) and MARQUEE element. Allowing user to stop these effects right on page load, and further giving the option to arbitrarily start/stop them later. Any DOM scripting/DHTML effects would be outside the scope of this, as too difficult to detect automatically (see normative exclusion 2).
3.4 Toggle scripts (P1)
No problem – option to stop/ignore javascript already implemented in browser preferences.
3.5 Toggle automatic content retrieval (P1)
Related to 2.4, browser should offer preferences option to ignore META refresh/redirect and any javascript that is not the direct result of user interaction. This would also cover things like AJAX / XMLHttpRequest and timed/delayed scripts. Could also allow a configuration option to request explicit approval from user, even if content retrieval is the result of user interaction (e.g., user clicked on an image which now wants to reload the page through some scripting – pop up a dialog “this page is attempting to load [URL]. allow/deny”)
3.6 Toggle images (P2)
Related to 2.3 and 2.9 – not quite sure of the distinction here.
Guideline 4. Ensure user control of rendering
Ensure that the user can select preferred styles (e.g., colors, size of rendered text, and synthesized speech characteristics) from choices offered by the user agent. Allow the user to override author-specified styles and user agent default styles.
4.1 Configure text scale (P1)
Browsers do offer text resizing, although IE still does not scale px sized text. Firefox implements a minimum size for text, which can be set in the preferences – a useful feature that would be of benefit to users in all other browsers
It would be great (also in light of 11.7) to have text size buttons/toolbar immediately visible in the browser’s default interface, to fill the usability gap of users not being aware that they can actually change the text size of a page without the need for in-page text size widgets and other such workarounds.
4.4 Slow multimedia (P1), 4.5 Start, stop, pause, and navigate multimedia (P1), 4.6 Do not obscure captions (P1)
Should be handled by the plug-in, unless the technology used does not yet allow this, or it is easier to implement via scripting from within the browser itself (though this blurs the lines of responsibility between browser and plug-in).
4.7 Global volume control (P1)
May be overkill to require a volume control at browser level. The volume control provided at operating system level should suffice.
4.8 Independent volume control (P1)
Should be handled by the plug-in.
4.14 Choose style sheets (P1)
Browsers need to implement a native way to persistently switch between alternate (and possibly different media-specific) style sheets to satisfy “Allow the user to choose from and apply alternative author style sheets (such as linked style sheets).”
Certain extensions and add-ons that fill this gap for browsers such as Firefox exist, but this should really be part of the core functionality. Also, these controls should be obvious, possibly as an option/toolbar right in the browser’s main interface; could also be made to appear, similar to pop-up blocking notifications, when the browser detects the presence in markup of alternate style sheet definitions.
Including a “no style sheet” option would satisfy “Allow the user to turn off (i.e., ignore) author and user style sheets.”
Handling of user style sheets is still very clunky. A better way would be to handle this would be through a mechanism and resource similar to browser themes – provide a centralised web repository for ready-made user style sheets that can be downloaded and selected in a user friendly dialog.
Guideline 5. Ensure user control of user interface behavior
Ensure that the user can control the behavior of viewports and user interface controls, including those that may be manipulated by the author (e.g., through scripts).
5.1 No automatic content focus change (P2)
Though the guideline seems to be primarily concerned with viewports, the definition would benefit from being applied to any kind of automatic focus changes. The latter could be handled by an option in the preferences to suppress any focus/blur events not triggered as direct result of user interaction (e.g. onload="focus…").
5.2 Keep viewport on top (P2)
Should be handled at operating system level for things like actual browser windows. However, it could arguably be applied to things such as tabbed browsing. No known issues at this stage, though.
5.3 Manual viewport open only (P2)
Effectively pop-up blocker functionality. Implemented in most modern browsers.
5.5 Confirm form submission (P2)
Could be handled by an option in the preferences to trigger a dialog whenever a form tries to submit in a non-standard way (e.g. onchange="submit()").
Guideline 8. Implement specifications that benefit accessibility
Support the accessibility features of all implemented specifications. Implement W3C recommendations when available and appropriate for a task.
8.1 Implement accessibility features (P1)
This could be seen as a catch-all checkpoint that includes many of the issues already mentioned:
- Provide sensible access to
longdesc(for mouse and keyboard users alike) - Keyboard access to
titleon arbitrary element (which would presume the ability to focus on arbitrary element via the keyboard as well) - Offer preference option to automatically expand
ABBR/ACRONYM - Possibly offer a visual way to identify headings that apply to the current cell in a table (for both mouse and keyboard navigation) – this could also count as an orientation feature for 10.1
- Native handling of
longdesc,citeattribute inBLOCKQUOTE… all the things browsers may acknowledge, but not present to the user LINKnavigation, spatial navigation, style sheet switching may fall under this as well
Guideline 9. Provide navigation mechanisms
Provide access to content through a variety of navigation mechanisms, including sequential navigation, direct navigation, searches, and structured navigation.
9.3 Move content focus (P1)
For point 2, “Allow configuration so that the content focus of a viewport only changes on explicit user request.” this could be coupled with 5.1 to disallow focus/blur, as well as calls to scroll functionality, which are not the direct result of user interaction.
9.4 Restore viewport state history (P1)
When going back/forward in the browser history, make sure that focus is on the element that it was on originally, and that the viewport is set to the same place.
9.5 No events on focus change (P2)
Preferences option to suppress focus/blur/change event handlers (although the browser may present the user with a dialog to allow/deny any such event)
9.6 Show event handlers (P2)
This could be handled by a context menu option to list event handlers with option to then explicitly trigger these events. IBM’s Home Page Reader (HPR) provided this sort of implementation.
9.8 Provide text search (P2)
It’s worth noting that certain user groups (such as screen reader users) have been known to make extensive use of text search as a quick orientation feature (in a similar way to sighted users visually “scanning” a page quickly for certain keywords). Particularly Firefox’s find as you type feature is commendable for its ease of use.
9.9 Allow structured navigation (P2)
Opera leads the pack here. Other browsers should implement similar strategies to allow for more efficient keyboard navigation to headings, paragraphs, lists, etc. Not necessarily having separate keys for navigating these different types of content, but a mode of navigation that skips from certain block level element to block level element (e.g. “tabbing” from a heading to a paragraph to a list).
Native support for LINK navigation – particularly if you interpret LINK references to prev/next as sequential navigation in the light of this checkpoint. Incidentally, this would allow defining a “skip to the content” link as LINK, removing the need to have it in the actual page body itself.
9.10 Configure important elements (P3)
Not currently available in Opera. Coupled with 9.9 and 10.4, this could be a simple dialog / set of checkboxes to say what to include in outline view and “structured navigation” mode.
Guideline 10. Orient the user
Provide information that will help the user understand browsing context.
10.1 Associate table cells and headers (P1)
Browsers may do this internally, but it’s not something that’s exposed to visual users. Perhaps an option to do row/column highlighting for keyboard/mouse users and a way to trigger a tooltip showing which headers apply to the current cell (the equivalent of a “where am I” function available in most screen readers).
10.3 Single highlight configuration (P2)
Possibly offer configuration option for users to change the visual cues for outlines. Colours for highlighted text should be taken from OS-wide configuration.
10.4 Provide outline view (P2)
A native linearise this page feature, coupled with a headings-list, would be useful.
10.5 Provide link information (P3)
Again, keyboard users don’t receive any information on possible title attribute. It would be useful if the browser could be set to denote internal (within the same document) and external links (and maybe even break this down further to distinguish between links within the current domain and links to other domains).
Additional information (such as date last visited, number of visits, media types) could also be presented to users on request.
10.7 Indicate viewport position (P3)
Should be taken care of already by default scrollbars. For elements styled via CSS to have hidden or no overflow, this may require an additional option in the preferences to force the appearance of a scrollbar?
Guideline 11. Allow configuration and customization
Allow users to configure the user agent so that frequently performed tasks are made convenient, and allow users to save their preferences.
11.2 Current author input configuration (P2)
Provide a dialog or similar that lists all accesskey bindings in the current page – and maybe even allows editing these to user’s preference, making that choice persistent across visits to that site. As an implementation proof of concept, see Gez Lemon’s Access Keys Greasemonkey script.
11.3 Allow override of bindings (P2)
It would be great if a user could configure/remap keyboard shortcuts to suit their needs.
11.4 Single-key access (P2)
As part of 11.3
11.6 User profiles (P2)
Handled in most browsers either at OS level (preferences tied to user that logged in) or by having explicit profiles (Firefox).
11.7 Tool bar configuration (P3)
Text size buttons/toolbars should really be visible in the default browser interface. As an alternative, the user could be given the option to display these types of access facilities the first time they run the browser.
Where do we go from here?
Browsers have been consistently getting better over the years, incorporating many innovative ideas (such as native RSS support). However, there is still a lot of functionality which would benefit all users (with or without disabilities). In the end, it’s about granting users more refined control over how their browser presents content, and how they are able to interact with the content to suit their needs and requirements.
Some of the comments and suggestions in this article certainly represent edge cases, and in some cases add-ons and extensions already provide workarounds for end users…but it would still be possible for a lot of the suggested features to be added natively to browsers without compromising their “normal” operation in order to close the usability gap, as Alastair Campbell put it in a recent article (which I dare say may have been partly inspired by our discussions in the previous months, while I was still tinkering away at this write-up).
The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.