W3C home > Mailing lists > Public > public-uaag2-comments@w3.org > January 2014

Some comments on UAAG 2.0

From: Shwetank Dixit <shwetankd@opera.com>
Date: Tue, 28 Jan 2014 22:30:00 +0530
Message-ID: <CAERMemdxt4wGYEZ77N87rhFwy2oTrjMvA-nPdMk1+u72N4T_ew@mail.gmail.com>
To: public-uaag2-comments@w3.org

Thanks for asking for comments on UAAG 2.0 and I'm glad to provide feedback.

The following points are some of things that we feel need to be addressed.

## Definition of User Agent

On a higher level, the definition of 'User Agent' is too broad. More
specifically, 'web based user agents' are essentially websites, and
thus should comply by the WCAG guidelines rather than the UAAG. So let
us please keep 'web based user agents' which are essentially web
apps/webs sites out of the definition of a 'User Agent'.

## Document should look beyond desktop browsers

For example

"Users can use the keyboard to navigate sequentially to all the
operable elements in the viewport (2.2.1, Level A) as well as between
viewports (2.2.2, Level A), and the default navigation order is
document order (2.2.3, Level A). Users can optionally disable wrapping
or request a signal when wrapping occurs (2.2.4, Level AA)."

The above might make sense in desktop browsers, but on other kind of
browsers like mobile browser on certain platforms, TV browsers, it
might not make sense.

## Some other specifics

** In Guideline 2.10 - Help users avoid flashing that could cause seizures **

"To help users avoid seizures, the default configuration prevents the
browser user interface and rendered content from flashing more than
three times a second above luminescence or color thresholds (2.10.1,
Level A), or even below the thresholds (2.10.2, Level AAA)."

Maybe I'm not understanding this correctly, but I'm not sure how
browsers could predict flashing  content in a video and prevent it
ahead of time. A lot of video on the web is in the form of a plugin
(like flash) which is essentially sandboxed outside of the browser's
direct control itself so even determining if that video is flashing is
difficult at best. So this seems a bit overly difficult to actually
implement in real life.

Ultimately, I think it should be up to web authors to follow the WCAG
guidelines regarding flashing content and including it here in the
UAAG is not prudent. You *could* however, mention it here that user
agents should not allow flashing content in the part of the UI like
the browser chrome or the settings pages etc - though I think its
improbable that browsers will ever do it on purpose as it is.

** In Guideline 1.10 - Provide element information **

"The user can access information about relationships between elements
(e.g. form labels, table headers) (1.10.1, Level AA), and extended
link information (e.g. title, internal vs. external) (1.10.2, Level

I think there are browser extensions which do a similar job, and if
not, can be made to do a similar job.

In general, a lot of the guidelines in the UAAG would be better solved
if we let browser extensions do the job rather than ask user agents
themselves to do it. I would very strongly suggest the guidelines
allow the user agents do the things mentioned in the guidelines
themselves, or *alternatively provide an API for extensions to be able
to do it*.

** In Guideline 3.1 - Help users avoid unnecessary messages **

"Users can turn off non-essential messages from the author or
user-agent (3.1.1, Level AA)."

It's not clear what 'non-essential' means. It is highly subjective,
and would defer from web app to web app and from user to user. In
general, we try to make sure we ask as little from the user as
possible, but sometimes asking for permission is important. I'm not
sure on what criteria would compliance be judged with respect to
something being considered 'essential' or 'non-essential'.

** Guideline 2.3 - Provide direct navigation and activation **

"Users can navigate directly (e.g. using keyboard shortcuts) to
important elements (2.3.1, Level AA) with the option of immediate
activation of the operable elements (2.3.3, Level A). Display commands
with the elements to make it easier for users to discover the commands
(2.3.2 & 2.3.4, Level AA). The user can remap and save direct commands
(2.3.5, Level AA)."

and also the following

"Elements determined as important by the user to facilitate the user's
navigation of the content. UAAG 2.0 intentionally does not identify
which important elements must be navigable because this will vary by
user needs and technologies being used."

Since important elements have been left at the discretion of the user
(and will vary from user to user, and from web page to web page) ...
It will be quite the task for the user agent to determine from the
user which elements he/she thinks is important and have the proper
facilities to navigate directly to it. Can make the criteria of
'important elements' more objective or easily definable?

** Intent of Success Criterion 2.3.2: **

"For many users, including those who use the keyboard or an input
method such as speech, the keyboard is often a primary method of user
agent control. It is important that direct keyboard commands assigned
to user agent functionality be discoverable, including in rendered
content. If direct commands are not presented in content, many users
will not discover them."

However, if we are to have proper documentation of the accessibility
functionality (Guideline 3.3) then, presumably, there it will be made
discoverable. Users will just need to go through the documentation to
discover all relevant controls.

In summary, I would emphasize the following main points:

* Tighten the definition of the User Agent (and remove 'web based user
agents' from it)
* Minimize subjectivity wherever it occurs in the guideline
* Make it so that browsers have the choice to either implement the
guidelines themselves or provide an API for extensions to make it
* Try to look again the wording and intent of some of the criteria
keeping mind non-desktop devices too (mobiles, TVs etc).

Best regards,
Shwetank Dixit
Web Evangelist,
Web Standards Team,
Opera Software - www.opera.com
Received on Tuesday, 28 January 2014 17:00:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:43 UTC