W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2005

RE: Techniques for GL 4.2 L1 SC6

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Mon, 31 Oct 2005 23:52:42 -0600
To: <w3c-wai-gl@w3.org>
Message-ID: <007401c5dea8$7aea13c0$ee8cfea9@NC6000BAK>

Yes and no

We have to remember that the whole purpose of 4.2 is to cover those
situations where the user agent is essentially shipped as part of the
content.    In those cases all of the User Agent access processes don't
work.  So we need to build something in here.   

We also shouldn't confuse Interfaces that are part of content with
interfaces that are part of user agents.  They both have to follow the same
rules (hence the guidelines look like UAAG guidelines) but User Interfaces
in content are not user agents and have to be covered here. 

As to specifics

How about a technique that says

Providing an event (that is exposed to AT through the standard AT API for
the technology being used) whenever a change to structure, selection, focus,
attributes, values, state, or relationships occur.

Then we need some examples like using Java Swing Classes. 

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Michael Cooper
Sent: Monday, October 31, 2005 2:31 PM
To: w3c-wai-gl@w3.org
Subject: RE: Techniques for GL 4.2 L1 SC6

What I hear Becky saying is that the intent of this success criterion falls
wholly - not just partially - in the user agent's responsibility.
Some of the other comments in the wiki seem to be asking that too, once I
see things through Becky's lens.

I guess I would say that this is a functional requirement, that we would
hope user agents would handle, meaning no author responsibility, but we
would expect authors to do something in case of any UA problem. In WCAG 1.0
days there were known problems in this area, which is why it occurred to us
to create this SC. If there are no longer such problems, so we can't think
of any necessary authoring techniques, then we might question its value. We
could do a couple things:

* Assume present and future technologies will automatically fulfill the
intent of this, and / or that other specifications, such as UAAG, will take
on the requirement, and remove the SC.

* Keep the SC because we think it's important, mainly as a beacon for
technology developers, even though there are no authoring techniques for it.

* Come up with specific authoring techniques, or ways to fail, that
demonstrate the need to keep this SC. I guess that was my job on taking an
action item for this and I haven't yet succeeded to everybody's

With those three possible approaches on the table, does anyone have a
preference for which way we go, or data to support choosing one over the
other? It seems to me the weight of opinion is leaning towards the first one
unless someone makes a strong argument for one of the others.


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Becky_Gibson@notesdev.ibm.com
Sent: October 31, 2005 3:06 PM
To: w3c-wai-gl@w3.org
Subject: RE: Techniques for GL 4.2 L1 SC6

Regarding the techniques for GL 4.2 L1 SC6

I'm not sure what "Providing an event whenever a change to structure,
selection, focus, attributes, values, state, or relationships occur. " 
means?  As a JavaScript programmer I generally respond to system events
rather than providing them.  There is a DOM api,
which can be sent to a particular node. Do other technologies such has Flash
have the concept of providing an event? 

I can see using DHTML Accessibility to satisfy some of this success 
criterion but even then, I'm not sure how to deal with focus?   I can 
programmatically set focus to an object by calling object.focus(). But, I
have to first be using an object that can accept focus - either a form 
element or link or I have set the tabindex value on the object.   Is 
calling focus on an object considered programmatically determined since it 
is in the script?    The user agent has to do something with that method

call (usually by generating a focus event).  As the programmer, I am relying
on the user agent to generate the focus event for that object and the AT to
acknowledge that focus.  Is a success criteria about that really necessary?
Maybe not for HTML but perhaps for other technologies? 

I have the same question about changing values?  In HTMLand JavaScript I can
programmatically change the value of an input type=text field. If I then set
focus to the field, the AT should pick it up.  I'm not sure there are really
any specific techniques for this.  If the call to
inputObject.focus() is in the JavaScript code then isn't it automatically
programmatically determined? 

Regarding the script technique:
Writing new content directly to the DOM  - while this is the preferred way
to add new content, there is no guarantee that the AT's will pick it up.

For example, if you add the new information at the top of the page and then
do not set focus to it, the AT user may never know the information has been
added. But, if focus is set the change in focus may be unexpected and you
could be violating GL 3.2 L1 SC1 or L3 SC2. 

Also, using document.write is listed as a common failure. While my advice is
to create objects via the DOM,  when done right, document.write can be
identified by AT.  I generally don't recommend document.write because it

is not useable in XHTML and thus code will have to eventually be rewritten
if migrating from HTML to XHTML. So, perhaps it can stay as a common failure
but the reasons need to be identified.

I'm not at all sure I see the need for this success criterion.  Is the focus
really more on future technologies?  It still seems like we are specifying
requirements on the user agent rather than the web content.

my two cents,

Becky Gibson
Web Accessibility Architect
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
Received on Tuesday, 1 November 2005 05:52:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:56 UTC