RE: Wendy's analysis of UAAG Guideline 6

Responses inline, preceded by "js:"



UAAG 1.0 Guideline 6 can be boiled down to, "Implement interoperable 
interfaces to communicate with other software (e.g., assistive 
technologies, the operating environment, and plug-ins)."

Therefore, WCAG boils down to what the author provides so that the 
appropriate information is communicated via the APIs.  This includes 
everything from the alt attribute on the img element to using structural

elements properly (to fill the DOM in a meaningful way) to role and
state 
information of scripted/non-standard/non-default 
widgets/elements.  @@question about the API related to the DHTML roadmap

*UAAG 1.0: 6.1 Programmatic access to HTML/XML infoset (P1)* This
checkpoint refers to the XML infoset [1].  Seems to me as long as an 
author uses any XML-based language according to spec, they will have 
provided all info according to the infoset and therefore the UA will
have 
the info needed to satisfy provisions 1 and 2. Provision 3 says, " If
the 
user can modify the state or value of a piece of HTML or XML content 
through the user interface (e.g., by checking a box or editing a text 
area), allow programmatic read access to the current state or value, and

allow the same degree of write access programmatically as is available 
through the user interface."Here, the author needs to provide state or 
value information if the user agent is unable to determine state or 
value.  It seems that the DHTML roadmap is helping ensure, "allow the
same 
degree of write access programmatically as is available through the user

interface" but I'm not sure what that means for the author.

Js: This seems like an issue for screen readers (for example) that walk
the DOM when they load a page but don't look at it again to catch any
changes made through scripting. So maybe this would involve some
client-side scripting techniques for the two baselines where scripting
is enabled?


[1]
<<http://www.w3.org/TR/xml-infoset/>http://www.w3.org/TR/xml-infoset/> 
(UAAG 1.0 references the Oct 2001 draft. The most current is Feb 2004)

*UAAG 1.0: 6.2 DOM access to HTML/XML content (P1)
*Specific to HTML.  Only DOM Level 2 Core.
"Note: This checkpoint stands apart from checkpoint 6.1 to emphasize the

distinction between what information is required and how to provide
access 
to that information." - seems to say that as long as we've provided all
the 
info needed for Guideline 6.1, the UA will have all of the information 
needed to communicate with other software.

*UAAG 1.0: 6.3 Programmatic access to non-HTML/XML content (P1)
*"Note: This checkpoint addresses content not covered by checkpoints 6.1
and 6.2."* *If providing a custom widget ensure UA has state and value
info (ala UAAG 
6.1).  If we write a general enough requirement for 6.1, then is there 
anything additional required for this Checkpoint?

*UAAG 1.0: 6.4 Programmatic access to information about rendered content
(P1) *Even if the delivery unit causes creation of a new viewport, it is
the UA 
that is rendering the perceivable unit and will therefore know the 
coordinates and provide access to content via points 6.2 and 6.3. i.e.,
if scripting causes a pop-up window, the UA actual creates the window
and 
knows about its contents.  if java or flash cause a pop-up, their VMs 
should provide programmatic access to them.  Therefore, nothing
additional 
for the author to do.

*UAAG 1.0: 6.5 Programmatic operation of user agent user interface (P1)
*If we distinguish between the viewport and the "user agent user
interface 
controls, selection, content focus, and user interface focus,"  then the

author has nothing additional to do for this UAAG checkpoint.  
Js: agree 
Event 
handlers provided in the delivery unit and instantiated by the user
agent 
do not render focus and selection - the handlers will provide
instructions 
for when and how to change focus and selection but the UA will actually
do 
the work.  Although, see the next checkpoint.

*UAAG 1.0: 6.6 Programmatic notification of changes (P1)
*"The user agent is not required to provide notification of changes in
the 
rendering of content (e.g., due to an animation effect or an effect
caused 
by a style sheet) unless the document object is modified as part of
those 
changes."  Therefore, the requirement is for the author to ensure that
the 
document object is modified.  If the author does something in such a way

that it is updated appropriately by default, then they don't have
anything 
more to do. If the document object is not modified appropriately, the 
author needs to update it. @@techniques-o-rama - related to baseline.
Js: agree-- my comment about 6.1 probably makes more sense here.

*UAAG 1.0: 6.7 Conventional keyboard APIs (P1)
*No requirements for authors.
Js: agree


*UAAG 1.0: 6.8 API character encodings (P1)
*Assumes authors are providing proper character encoding information.
Js: Hmmm. Nothing in WCAG seems really to cover this. It's related in
some ways to 3.1 L1 SC1 (identifying natural language of the delivery
unit), in the sense that identifying the text-processing language (as
discussed by I18N) may affect the rendering of characters (e.g., glyphs
shared among Chinese, Japanese, Korean but having a somewhat different
apperance in each language). But this seems to have something to do with
Principle 1 as well-- we have lots of stuff aimed at making *non-text
content* perceivable, but we take it for granted that *text* is
perceivable by default.


The following sections seems relevant and interesting, although I can't 
quite figure out how:
Normative inclusion: For content, user agent features, or both
<<http://www.w3.org/TR/UAAG10/conformance.html#content-or-ua>http://www.
w3.org/TR/UAAG10/conformance.html#content-or-ua>js: hmmm. If I read the
UAAG material right, does this mean there are notations throughout UAAG
that identify checkpoints where the content is responsible for doing
something so that the UA can render it? If so, do we need to review UAAG
looking for those notations?

John

Received on Saturday, 23 April 2005 20:12:45 UTC