DRAFT - Input to Guidelines from UAWG

Jim- 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.

We wrote the document with user needs as a basis for guidelines. UAAG20 lays out most issues and strategies for solving them. Different audiences may find different presentations useful to them. We have created a companion document - UAAG20-Reference that contains use cases.

Many of the issues below have Success Criteria associated with them. However, user agents are continually evolving and new issue arise as platforms and interaction models are introduced.

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 and their solutions may fail in some user agents.

The difference between UAAG 2.0 and a future requirements document: UAAG was based on WCAG model, but while it is important for authors to use one solution to a user problem, the user agents can design different solutions to the problem. We hope it would be more effective to have use cases of disability needs for user agent vendors than to have a strict document like UAAG 2.0.

Whose Responsibility?

Jim - I think the content in the "whose responsibility" section is relevant, but the framing needs to be tweaked, for instance as "Current challenges" and to avoid anything that may sound like hyperbole "millions of authors" etc because it's a strong statement and I doubt you have clear data to back that up. Or even just "many" rather than "too many." It actually makes the same point, and is clearer ("than what?") I think a categorical statement of what the browsers role *is* may not be received well at all (as currently in the statement of problem). I think an aspirational statement might be "heard" much better.

WCAG's “technology supported” requirement has been interpreted by authors and web developers that they are responsible for accessibility.  But this is not a workable long-term solution to web accessibility problems.  Authors are responsible, but not wholly responsible.

• Individual authors create many solutions to an accessibility issue instead of browser-based solutions which have consistent behavior.
• Many authors are not trained in accessibility
• Many authors code incorrectly – mistakes or omissions in coding, or only planning for one type of disability.
• 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. 

Solutions

Jim - Solutions: It may be puzzling to some readers why this level of guidance wasn't included in UAAG 2.0. This section needs more context.

@@ add SC(s) to each solution. those with are SC are newly evolved.

Most of the examples are addressed in UAAG 2.0, but they are still problems for people with disabilities. Since the need still exists, they should be repeated in a forum that is more acceptable to the user agent vendors. The solution is to implement UAAG20, with particular emphasis on 5.1.1 and 5.1.2. We recommend browsers incorporate accessibility into their development processes such as testing, beta testing, and training.

Create a user requirements document (like Mobile Accessibility User Requirements) 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.
• User agents implement UAAG 2.0

Examples of Accessibility Problems best solved in the User Agent

jim-again, I think this needs context for why these weren't already included in UAAG, if they weren't, and why they should be in future combined guidelines, to be useful input going forward. It may be a simple explanation, or there maybe something I'm missing in terms of your intent.

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 changed.

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 alternative text.

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 regard.

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.

Keyboard shortcuts: Provide a means for users to change and coordinate keyboard shortcuts across applications. Provide a way for users to save and share keyboard shortcuts.

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).