Re: 4.1 work in progress

Regrettably, the following comments are rather terse due to other time
pressures, but I trust they will be useful to the working group. I noticed
this proposal on the list and thought commenting was warranted.
On Tue, Mar 07, 2006 at 04:47:09PM -0600, Gregg Vanderheiden wrote:
> 
> DEFINITIONs 
> 
> PROGRAMMATICALLY DETERMINED 
> determined using software services that are supported, publicly documented,
> and implemented by assistive technology. 
I agree with all but the "implemented by assistive technologies" part, which
should say "implemented by user agents". According to UAAG definitions adopted
in WCAG, user agents include assistive technologies. However, "assistive
technologies" do not include all user agents, with the consequence that if
something is implemented in, for example, Web browsers designed for
accessibility (e.g., "self-voicing" etc.), it won't satisfy the definition.
> 
> PROGRAMMATICALLY SET 
> set using software services that are supported, publicly documented, and
> implemented by assistive technology. 
Same comment as above.
> 
> PERCEIVABLE PROPERTIES
> information about the identity, nature, and state that are presented to the
> user. 
A disingenuous interpreter could argue that because a certain property isn't
presented to, say, screen reader users then it isn't a perceivable property.
The problem is that this interpretation isn't ruled out by the language of the
definition. Perhaps it should say "may be presented to the user", but that could
be overly inclusive. I think the definition is in need of a rewrite, but I
don't have a quick answer other than the above proposal, which would need to
be looked at carefully to determine whether it's workable.

> Guideline 4.1 Enable compatibility with current and future user agents
> (including assistive technologies)
> 
> 4.1.1 Web Pages (including Web
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Web_Pages_%28including_Web_
> Applications%29&action=edit>  Applications) can be parsed unambiguously and
> the relationships in the resulting data structure are also unambiguous. [
> How_to_Meet_Success_Criterion_4.1.1
> <http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Success_Criteri
> on_4.1.1>  ]
In comments responding to the November 2005 draft submitted to the official
mailing list for such comments, I argued that the "can be parsed
unambiguously" requirement is vacuous, unhelpful to accessibility and and an
inadequate substitute for a more substantive requirement for conformance to
specifications. Those considerations remain applicable to the present
proposal. As those comments are (or should be) in the issues list, I trust
they will be given due consideration before this or a related proposal finds
its way into the guidelines.
> 
> 4.1.2 For each user interface component in the content, the name
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Name_attribute&action=edit>
> , role
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Role_attribute&action=edit>
> , and all perceivable properties
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Perceivable_attributes&acti
> on=edit>  can be programmatically determined
This is fine, subject to the issues raised about the definitions.
> 
> NOTE: SC 4.1.2 through 4.1.4 are usually automatically met by HTML and other
> markup languages in conjunction with accessible user agents unless authors
> <http://trace.wisc.edu/wcag_wiki/index.php?title=Programmatically_determined
> &action=edit> programmatically determined. 
> are creating their own user interface components in software. 
[...]

The remainder of these seem reasonable enough. What's missing, though, is a
substantive requirement of correctness according to specifications, which is
what this guideline was originally intended to demand and which I maintain it
should continue to require. This proposal sets out no requirements for
non-user-interface components of the content, presumably meaning components
that don't accept input from the user. Thus one can satisfy guideline 1.3 in
ways that user agents, in general, can't interpret without thereby failing to
meet 4.1.

Received on Wednesday, 8 March 2006 06:59:32 UTC