03 December Minutes from Techniques Task Force Telecon

IRC log at: http://www.w3.org/2003/12/03-wai-wcag-irc.html

Summary of action items:
ACTION: wendy find out if "work has ended" in 7.1.2 of W3C process document 
means "stabilized" or "discontinued" - and how that applies to our use of 
WG Notes to publish techniques 
docs.  http://www.w3.org/2003/06/Process-20030618/tr.html#q71
ACTION: wendy follow-up on s. african contacts from tom
ACTION: tom work with lisa on editing rdf techs.
ACTION: chris will look into who is available for testing (at atrc)
ACTION: ben set up form to collect info about tools for testing (and gather 
volunteers to test)

Next week's agenda:  RDF and CSS Techniques.  Invite Lisa and Tim to attend.

chris reports on latest work: the validator now runs several of the 
checks.  has been looking at information about testing for color.

jenae has been reviewing the QA documents. we're probably most interested 
in test guidelines. there are 7 documents. intro, operational guidelines, 
specification guidelines, test guidelines.  depending on your role, 
(editing) may want to read spec guidelines.  others may need to read all. 
also have a "qa process document template" not clear if it is for every doc 
or the working group.

wac gives summary of f2f meeting discussion w/karl and olivier (from qa wg 
and ig).  Olivier will be the QA to WCAG liaison, the WCAG WG needs to 
choose a WCAG to QA liaison (Kerstin expressed interest at the F2F 
meeting).  Some of their documents are in Candidate Recommendation right 
now, and we will be providing feedback and acting as an implementation test 
for them.  Olivier will be reviewing our documents and working group 
process through the QA lens.

tom still plans to write client use cases. then can say "this checkpoint" 
or "this technique" is applicable to x, y, z use case. use cases: to 
justify what we're doing. making sure that what we produce is helping clients.

Tom attended meetings of task forces 2 and 3 at the EuroAccessibility 
mtg.  task force 2: producing atomic tests (similar to what Chris is doing) 
- granular level, what constitutes compliance to wcag 1.0. task force 3: 
developing a methodology to compare tools to the list produced by 
tf2.  which tools complete which tests. tf2: alistair garrison is the 
chair. would like to finish before the end of the year (at least for 1st 
round). spent a couple of days talking about the 1st 5 checkpoints and 
hammering out how to identify a text equivalent.  starting from scratch on 
some of these. many members brought checks with them. took brief look at 
chris' work.

Michael is meeting with Alistair on Thursday and will report next week 
about that meeting.

There is concern that they are working off of WCAG 1.0 Techniques, which 
are out of date. Also, concern that WCAG 1.0 has known errata and request 
to publish an update.

How can we clarify how WCAG 2.0 techniques apply to WCAG 1.0 (both to ease 
the transition from 1.0 to 2.0, as well as to keep 1.0 techniques 
up-to-date)?  We have discussed a mapping in XML source to both WCAG 1.0 
and WCAG 2.0.  even if we don't backport the documents, mention somehow 
that more up-to-date techniqeus are available.  for people who aren't 
following inner-workings of WG, the documents they will use are 1.0 
techniques. there are some things that have been deprecated, put note in 
1.0 document or completely update them?

there was agreement w/alistair's point about updating 1.0 documents.

even if finish wcag 2.0 by end of summer, becoming part of policy will take 
a while. swiss law references "the latest guidelines from w3c."  italians 
recently passed something, reference 1.0.  many governments are not likely 
to do what swiss did, because of fear of instability.  it also doesn't 
solve the problem, the latest is a rec and not our working drafts.

(according to the process document) it is possible to release a "revised 
recommendation."  The issue is that it would take some of our attention 
into that process, rather than WCAG 2.0 development.  There are also issues 
with messaging and perception of instability.

there is some confusion about techniques documents remaining working drafts 
or maturing to notes.  wendy clarifies of use of "note" in new process 
document.  "note" is still a possible end-state, but it is now qualified 
(working group note, interest group note, coordination group note as well 
as member submission and team submission).  Before, all of these were 
labeled "note" and thus all carried the same weight.  Now, "working group 
note" indicates consensus by a working group while "team submission" is 
something written by a W3C team member.  The only use of "note" that will 
end is the unqualified use of the label.

action: wendy find out if "work has ended" in 7.1.2 means "stabilized" or 
"discontinued" - and how that applies to our use of WG Notes to publish 
techniques docs.

lisa - would like some help with rdf techniques. lisa looking for review. 
try to get charles involved (at least review).
http://www.ubaccess.com/rdf.html
action: tom work with lisa on editing rdf techs.

Tim joined a couple weeks ago saying he's been allocated time from NIST
Just did a review of old CSS techniques

===
gateway techniques

tom has bunch of stuff to put into the doc.

recent list discussion about scripts. what part of the discussion goes into 
script techniques and which into  gateway? what about svg? e.g., how do 
screen readers handle disabled forms? if svg or html require scripting to 
enable parts of the page, it is going to be inaccessible.

This relates to the question of whether script being enabled is mandatory 
for accessibility. WCAG 1 requires page function if script not supported, 
does/should WCAG 2?

css and scripting, always used w/other technologies, thus should we produce 
self-standing techs docs or chapters w/in other techs? support of script an 
accessibility issue? how essential is the function?

determine if it is easiest to say "all these things are inaccessible, rest 
fine." or "these are the only things can do, all else bad"

need to tease out which get handled in script techs and which in gateway.
e.g., gateway: script supported by user agent, general info, e.g., 
"roll-over scripts tend to be ok, if you use disable attributes..."
script techs: the script code that enables form controls, dynamic menus, 
and specific dos and don'ts

when we refer to script techs we are talking about ECMAScript (rather than 
vbscript or others)

proposal: if use script to enable parts of a page, make sure that is not 
disabled by default. e.g., print icon. script generates it, only activated 
by script. if don't have script, don't get it.  only people who see it have 
javascript on, thus don't run into issue of having a button that is 
unusable if scripts aren't running.

the script doesn't provide essential function, thus an elegant solution.
what about web applications? if no script support, can't use.  e.g., web 
app (windows app ported to html)

if you need that rich function, will you need to find server-side 
solution?  discussion that for validation, ought to have server-side 
backup, but what about interaction?  Should there be the capability of 
falling back to less rich but still nominally accessible functionality?

Example of web app that relies on scripts is the tree view of a file 
system. An approach to the tree control is that it's done as nested lists, 
using CSS to format as tree and Javascript to provide the functionality. 
The fallback is that there are regular links that do the annoying refresh 
or whatever, but it still works

concern about legacy systems and how difficult it can be to change.

What about browsers where scripts don't function? how do we address that 
today? in 1.0, proper decision to say sites must work w/out scripts. what 
do today? have to do the research. how many people using browsers that dn't 
support scripting? unattainable data? logs know in theory if browser 
supports, but what about peple who have disabled it? there is a way to 
test, but people would have to hit a specific site.

tom will have some people who can test browsers and asst. techs. suggestion 
to add a component to the techniques product to keep track of tests that 
need to be done?

action: chris will look into who is available for testing (at atrc)

need a list of user agent and asst tech combos that support techniques? 
when test for assitive technology and browser, there is a large number of 
combinations, versions, platforms, etc. do we have a core list of user 
agents that we want to be sure that each technique work with? i.e., for it 
to be included, a technique must work with x,y,z browser and/or assistive 
technology and user agent combination. do we need a lowest common 
denominator to test with? come up with a list of software and hardware that 
people (in the WCAG WG) have and can use for testing? Information we would 
need about each product: name, version, platform, manufacturer, hardware 
configuration (braille/audio, laptop/desktop, sound card, system, os, etc.)
interesting to see what list of tools we come up with. concern that the 
only tools we'll come up with (at this time) will be english-based. will 
need to find other testers. we met some potential testers while in japan - 
possibly a way to get people involved and bridge communication.

action: ben set up form to collect info about tools for testing (and gather 
volunteers to test)

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Wednesday, 3 December 2003 14:38:21 UTC