Minutes from 15 January 2001

Participants:
Len, Chris, Daniel, Wendy, Dick, William

Summary of action items and resolutions
Resolved: Name of language is EARL.
Action WC and LK: Go through issues and propose owner and resolution if 
possible.
Action LK: Ask AU on list, "Once AERT is part of AU, what do people have to 
do to achieve ATAG? How does AERT change as it moves from list of 
suggestions to part of a recommendation?  What does a tool <em>have</em> to 
do."
Resolved: we don't have a separate guidelines on testability and that each 
technique includes testability.
Resolved: Make a concrete proposal to WCAG for how to use EARL to make 
conformance claims and modify EARL accordingly to make claims that 
alternatives are equivalent.

Coordination of open issues
WC history of issues list: began list of open issues, then started marking 
in the document with @@'s. Need to bring the @@'s into the list. Some 
redundancy.
LK From AU's point of view.
WC history of development of the proposal: at AU f2f in May after WWW9 we 
broke into sub-groups to discuss ATAG Techniques. The group that I was in 
(Dick, Katie, and Andi?) created a mapping between AERT and ATAG Techs and 
proposed to group to combine.  AU accepted, but had to also take proposal 
to the WAI team and ER.  Also accepted and so it was done.
LK Responsibility for open issues?
WC Not sure. Depends on their response to open issues list.
LK Some are ER, some AU, some WCAG.
WC Likely to spend time on this Thursday a.m. Reads issues 11, 12, 13.
LK When this was part of ER this was not a part of a Recommendation, it was 
ideas that people could pick from. Once part of AU, what do people have to 
do to achieve it?
Action LK: Ask AU on list, "Once AERT is part of AU, what do people have to 
do to achieve ATAG? How does AERT change as it moves from list of 
suggestions to part of a recommendation?  What does a tool <em>have</em> to 
do."
CR Sounds like we review, then give to ER.
WC Issues list should be updated today.  We should review each issue at 
latest before F2F in February making decisions about which issue belongs to 
whom.
Action WC and LK: Go through issues and propose owner and resolution if 
possible.

Testability proposal for WCAG
LK Proposal is for a requirement in WCAG that pages be written to minimize 
the effort of testing. How do others feel about this requirement.
DB Not clear enough one examples.  What am I going to tell the MSN team 
what this is about? What can they change in their process?
LK It would be minimizing things that require a human check.  Use real-text 
rather than images of text. If you have 2 versions of a site, facilitate 
making a comparison between the two versions.  Putting same ids on same 
elements in different versions let you determine if they are 
equivalent.  In AERT, several places where says, "If you do this, requires 
a manual check." Therefore avoid those. Probably a P2 or P3.
WC Not making it accessible, making it easier to determine if it is accessible.
LK At MS, just tell developers make accessible or part of testing process?
DB Testing is not exact, but we work with testers to put it in their 
routines. This is not something I would support since I'm not sure what we 
would be doing. We have an alternative for the home page. I don't usually 
encourage alternatives. If talking about a specific site i'm not sure the 
advice I would give.  Making something easier to test would save us time, 
but not sure how to do.
WL Noble cause but perhaps too vague. Testability is our job - to make 
tools to test stuff.  What should be built into a file to facilitate 
testing is what your talking about.  It's difficult to identify that as 
accessibility problem rather than general software issue or good practise.
LK What about "avoid alternative pages" or "If you have an alternative page 
put identifiers on alternative to help find corresponding elements."
DB Making sure element appears in both version.  We dump info into 
templates. Why would you need to do that if you know that the source is the 
same and that it's a matter of a different look.
WL We're trying to call to put a label on an onion that's an onion. The id 
of putting a label on the instrument is absurd. We have 
guidelines/checkpoints that require an alternative thing to be identical.
LK The checkpoint could be: if you make 2 different versions and the both 
come out of a database there is a greater probability they will be similar.
WL We already have a checkpoint that says, when deal with alternative pages 
it has to be equivalent.
LK Nothing in WCAG 1.0 that makes a preference to generating page by 
database vs. by hand.
WL Not sure if that is true or if it matters. If good by hand, then fine.
LK In practise if you came to a site w/alternative pages, which site would 
you have more confidence in: the site that is done by hand or the one 
generated by database and template.
WL I would look at who did the site!
LK My feeling is that things that don't get checked don't work. In 
software, no checking you have bugs.  Anything you don't look at is wrong 
basically!  Software testers always find bugs.
WL I don't know what I'm voting on. If there was a specific proposal, I'm 
all for enhancing testability. I'm not sure if we have a specific means of 
doing it.
WC text as text rather than images is under use style for presentation
LK what about "associate equivalents?"
WC technique for providing equivalents or checkpoint under guideline 1
LK want to be able to find equivalent to verify that equivalent in 
alternative version is same.
WL Your proposing that LK takes an action item to write techniques section 
that deals with verification of alternative presentations.
WC in WCAG 2.0, requirement that checkpoints be testable. Therefore, expect 
to have more testing info in techniques.
LK ok
WL One of the technologies of techniques is general area of testability.
LK in requirements document, testability mean can it be easily be 
verifiable or verifiable.
WC reads item 2 from the WCAG 2.0 Requirements document 
[http://www.w3.org/WAI/GL/wcag20-requirements]
LK Possible resolution, we don't have a separate guideline for testability, 
but for each checkpoint add something to technique to satisfy the "make it 
easily verifiable."
WL Yes! That's exactly what developers use.
LK In the case of alternative versions of the site, we have a variety of 
versions (text, flash,e tc.) we want a quick link to show where this object 
is   in the other site. DB Was saying if something generated from database 
what do we need this for?
WL This is a major piece of the device independence activity. This same 
database's contents will have things to transform the content to a web 
phone and a web tv. Each instance will have to have the testability you are 
describing.
WC Subgroup from f2f discussing dynamic generation. This best covered by 
testing techniques in their techniques document.
LK I can set things up so that inside my style sheets I can convince myself 
that these are equivalent. A 3rd party tester might not be able to get 
inside. It might be hard for them to verify it.  Make sure these are 
testable from outside?
WC Using EARL developer makes a claim, they be responsible.
LK I want things to be verifiable by 3rd parties.  If i"m a government 
agency I want to verify for myself that something is accessible I don't 
want to depend on assurances.
WL As a fairly vague philosophical point, I agree, but I need something to 
put my hands on.
LK The specific case: if i have 2 versions of the site that have the same 
info but in different places I want to have labels to determine that the 
flash presentation in one version is saying the same thing as the text-only 
version. that requires that the code have identifiers so that I can match 
them up.
WL I can't think of an example where that wouldn't be the case.
LK How are you going to find the corresponding element if not labeled by an 
indentifier. In one case it's an object in another it's a paragraph. How 
can the machine tell?
WL How do they tell internally?
LK You could have 2 groups developing them. If they did it internally how 
does external person verify?
WC What if we require EARL in WCAG 2.0 conformance claims?  Then internally 
they would know the equivalent and express it in EARL. The only question 
becomes, how to verify by a 3rd party.
LK Ok. i can see that. It becomes part of EARL and the conformance claim.
WL Hurray.
LK Sounds like there is 3 things coming out of this discussion:
1. we don't have a testability as a separate guideline
2. however we do add to techniques for those checkpoints things that would 
make them easier to test.
WL What we are arriving at is that among the several techniques documents, 
one is on testability.
WC Testing in each techniques doc and that AERT moves to WCAG! 
<grin/>  Actually aspects move to WCAG other to AU.
LK 3. when have alternative versions of a site, EARL will state what 
corresponds to what and that's part of the conformance claim.
WL Yes, and part of device indie.
WC I agree with 1 and 2, but 3 is a proposal for WCAG for them to deal with 
once they get to conformance issues. I propose that we don't take it to 
WCAG until we have a concrete example such as ,"to make a conformance 
claim, here is the EARL syntax. specifically, to show that alternatives are 
equivalent, do this..."
Resolved: we don't have a separate guidelines on testability and that each 
technique includes testability.
Resolved: Make a concrete proposal to WCAG for how to use EARL to make 
conformance claims and modify EARL accordingly to make claims that 
alternatives are equivalent.

LK Discuss javascript or adjourn?
WL Part of forms, etc. Not part of HTML code. Hidden behind vapor wall of 
OBJECT or APPLET or SCRIPT. Each of them are external in that the 
testability can only be determined by delving. Specifically 
Javascript/ecmascript, flash, etc.
WC will report back after experience at IBM.
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Monday, 15 January 2001 11:17:02 UTC