- Important note: This Wiki page is edited by participants of the User Agent Accessibility Guidelines working group (UAWG). It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.
Thoughts for UAAG 3
DRAFT - Input to Guidelines from UAWG
DRAFT - Input to Guidelines from UAWG
Judy- People will need to understand the relationship between the work that you are completing (the WG Note) and these future-oriented suggestions. So you'd need to add some context for that. I could help you brainstorm on that.
Statement of problem
Some accessibility needs of people with disabilities are best implemented by browsers and user agents. The authors main requirement is to supply the content, not to provide additional accessibility features. If the author codes according to standard, then the content should be accessible. It's the browser's job to insure that “coding to standard” is accessible by default. Inconsistent implementation of standards such as HTML5, ARIA, CSS, etc. also forces author's to code around the deficiencies of user agents.
WCAG's “technology supported” requirement has been interpreted by millions of authors and web developers that they are responsible for accessibility. But this is not a workable long-term solution to web accessibility problems. They are responsible, but not wholly responsible.
- Individual authors create millions of solutions to an accessibility issue instead of browser-based solutions
- Too many authors are not trained in accessibility
- Too many authors code incorrectly – mistakes or omissions in coding, or only planning for one type of disability.
- Too many variations in user interfaces and interaction patterns
- The cost in time and bandwidth is too high for each author to provide a separate solution to each accessibility issue
- For some accessibility issues, the browser is in a better position to provide the solution: e.g. enlarging text, hiding images, keyboard accessible tool tips, etc.
It is the author's responsibility to write the text of a tooltip, it is the browsers responsibility to display the tool-tip from the keyboard in an accessible manner.
Create a user requirements document (like MAUR) that includes:
- All browser functions and rendering should meet WCAG by default
- Implement W3C standards in full, particularly HTML5 and ARIA. Polyfills are hacks - bad for accessibility. too many authors writing it wrong. browsers should implement html5 and ARIA
- User agents implement UAAG 2.0
Examples of Accessibility Problems best solved in the User Agent
<a name="body" id="body"></a>Alert on Autocorrect: the browser, application, or whatever has an autocorrect
feature. The user who is blind types information, the autocorrect changes
that information but give no indication that what was originally typed has
<a name="body2" id="body2"></a>Search Alternative Text: A blind employee who needs to search a specific entries in a photo gallery
or repository of charts can't, because most browsers do not search the
Overflow Content Keyboard Accessibility: Employees using a keyboard cannot read all the content contained in a
<div> with overflow, because in most browsers, they cannot use the keyboard
to enter the box and cannot move the scrollbars. Even cursor browsing won't
enter that overflow box.
Meets WCAG by Default: the default contrast of <option> in hover or focus state in <select> does
not meet WCAG, and is not styleable by the author.
Customize Text: People with low vision can't customize the text so they can read it when
browsers eliminate user stylesheets. Zoom is inadequate for people who
need to reduce space and heading sizes so the maximum amount of text
appears in their field of vision.
Printing Customized Web Pages: In most browsers, people with low vision can't print out a web page at the size or customization they need. These employees can't work without their
computer which limits their ability to do sales calls, or field service.
Point of Regard: An employee reading a long document can't resize the text or resize the
window without losing their place, because browsers don't keep the point of
Keyboard Accessible Tooltips: Users who want to read a tooltip from the keyboard can't in major browsers, because the browsers don't provide tooltips on keyboard focus. Elements
that can't get focus cannot display tooltips. This requires authors to go
through a lot of work to meet WCAG requirements for keyboard access.
WCAG Color Contrast: Placeholder text and disabled elements by default do not meet WCAG color
contrast requirements, so authors have to compensate to meet WCAG.
Keyboard Access: In additional, many web pages are designed to require a mouse. The browser
could provide alternative access for keyboard users, such as the ability to
tab to elements that have recognized scripted reactions to mouse input;
without this support the pages remain inaccessible to them. (As just one example, this prevents keyboard users from paying their property taxes online in at least one county.)
Keyboard Access to Security Information: The security status button next to the address can
be reached using the keyboard only by navigating BACKWARDS through the tab
order, which is not easily discoverable.
Keyboard Access to User Interface: Toolbar buttons are not accessible from the
keyboard (both those built-in and those added by extensions). You cannot customize the selection and order of toolbar buttons using the keyboard.
Generated Content: Generated content (e.g. by CSS) may not be exposed to assistive technology through platform API or the DOM, even though it appears to users indistinguishable
from other content and may be required to use the page.
Scaling Controls: Check boxes and other controls in content do not scale up with font size, leaving them difficult for some users to see or recognize.
Provide Keyboard Shortcuts: At least one browser running on Windows for the desktop does not assign
shortcut keys to the controls in its dialog boxes, failing to comply with
platform UI guidelines or accessibility guidelines, and vastly increasing
the number of navigation and keystrokes required to perform tasks.
Provide Default Setting for Captions On: The ability to display captions is very inconsistent in media players on
mobile browsers. Most mobile browsers do not respect OS settings to display
captions and don't provide their own control to turn it on.
User Choice of Screen Size: Content providers who provide different versions of their content optimized for different users, environments, input or output devices, etc., would let the user choose which they prefer rather than forcing them to view the version the site guesses they want (e.g. by browser identification or screen size).
Author proposes, user disposes with the help of the browser - paraphrases from Al Gillman