> EOWG Home > EOWG Minutes
agenda in e-mail list archives: http://lists.w3.org/Archives/Public/w3c-wai-eo/2005JanMar/0033.html
AA: has lot of 1-day workshops planned (web developers and managers) and registration is filling up fast
ATAG Glossary issues, from EOWG Lexicon Task Force
- original email from Henk:
* revisions from last week: to be sent to EOWG mailing list
JB: lexicon task force did some fast work on line and by Monday night Henk sent an updated version and there were a few comments on the list. The package of work did not include the suggested introduction (what EO's options are - our approach, modified approach or their approach) for ATAG and Henk asked Judy to do that.
ACTION ITEM: Judy to do draft today and to forward that plus today's comments to Jutta. There is still a short amount of time to do this. Not suggesting we spend much time going through comments.
CC: confused about "Repairing, Accessibility" (see her e-mail [LINK]).
That phrasing seems to be "out of the blue".
WD: also bothered him, had to read it a few times before he understood what he was seeing. Decided it meant, "repairing for accessibility". Not good as a sentence, but ok as a concept.
WL: would make sense in an index as a subtopic of "Repairing"
DS: we are not repairing accessibility, but a Web site to make it accessible.
JB: maybe "Repairing (accessibility)"
[Further grammatical discussion led to conclusion: "Repair (of accessibility problems)"]
for comments (and questions for review) on WAI IG list:
- ATAG 2.0 Last Call draft
- ATAG 2.0 techniques draft
* Comments on EOWG mailing list:
JB: Please look at Jan.
12 mail from Wayne
SLH: agrees with Wayne's comment: proposal is to take out first part of 1.4 and reference the components diagram and take out 1.4.2
WD: did not know when making his comments how important the ISO and XAG documents were to ATAG.
SLH: thinks its better to refer to these in Components document.
JB: agrees since XAG is not a stable document it shouldn't be referenced in ATAT 2.0
WD: in that case agrees with Shawn that the pointer should be to Components document.
JB: "Refer to the components document for more about XAG, but not to XAG directly"
WL: there is some precedent for referring to things that are not done but need to be done or are in process.
SLH: reminded William about the Components note (that can be updated) as opposed to the uneditable ATAG Recommendation.
JB: "Refer to the components document for more about XAG, but not to XAG directly"
[See Shawn's e-mail (Comment 1) for a summary of this item [http://lists.w3.org/Archives/Public/w3c-wai-eo/2005JanMar/0044.html]]
SLH: Last paragraph of 1.4 move into 1.4.1
JB: anybody disagree with this approach to improving the whole of 1.4 to make it better.
JB: now please look back at Wayne's comments on "2. The Authoring Tool
Accessibility Guidelines, Guideline 1: Make the authoring interface
accessible". Any comments?
[No comment on either point: add to our comments to ATAG]
"1.2 Ensure that the authoring interface enables accessible editing of
element and object properties."
HB: did not like what ATAG did with definition of "element"
WD: thinks they should use a different term altogether.
SLH: thinks they are talking about HTML element.
HB, ED: NO THEY AREN'T
SAZ: the idea behind it is that everything in HTML is an element (e.g. HTML, BODY) but agrees it is not the best way to describe it.
JB: will say to ATAG: "we thinks there is a contradiction, please fix it. It is ambiguous"
"1.4 Ensure that the authoring interface enables the author to navigate
the structure and perform structure-based edits."
SLH: thinks 1.4 is saying more than Wayne's understanding of it.
JB: should we say "this point should be re-examine the comment as a comment about usability feature rather than accessibility"? Add to the rationale Wayne's suggestion. Any disagreement?
WL: reminder that this was a very heavy sticking point when it was discussed at ATAG. Vendors didn't like it.
JB: Agrees, gut feeling is that this is usability, not accessibility.
WD: could we put the guideline in conditionally? "If you put it in you must make it an accessible feature."
JB: the rationale might be unclear for a different reason than Wayne is suggesting. This has been discussed for years. PWD wanting access to authoring doesn't explain it enough.
WD: agrees, but just doesn't want to loose the concept.
JB: in order to not have the rationale interpreted as "equal access" it needs more technical description of why navigating the structure is important. Shawn was worried about moving in this direction.
SLH: they did intend to say more than they did, but they need to clarify.
JB: another approach is that we have options as to what we send in as a group and what we send it as individuals. There seems to be some not entirely clear definition of the problem here. Made a suggestion.
DECISION: Judy has captured the comment in her notes, which will go to ATAG.
WD, WL: think Judy's suggestion is a good approach.
"Guideline 3 - Support the author in the production of accessible
JB: our scope is to help make what ATAG does clear. Is this more of a technical comment? If so, it should go in separately from EO's comment.
DECISION: Wayne will send it in as a personal comment.
"Guideline 4: Promote and integrate accessibility solutions."
JB: can anyone suggest something that would help this?
DECISION: We will submit a comment saying we tried, but couldn't figure it out.
"Introductory comments of the main guidelines 1, 2, 3 and 4 should include
hyperlinks to any terms that are defined in the glossary."
JB: any disagreement with incorporating that into our comments?
WL: made a suggestion: please check that any defined term occurring in the document link to the glossary term.
JB: thanked Wayne for his detailed comments.
WL: another comment on the 1.4.2 discussion and "primary audience"
WD: need to make clear audience (primary and secondary) in section 1.1. Can be removed from 1.4.
JB: will need to write up the collated comments over the weekend and send them to list. Now let's go to Pasquale's comments.
comments about ATAG 2.0 WD 22 nov 04
"1.3 Role of authoring tools in Web accessibility"
[Some discussion: consensus - worth fixing]
SLH: Suggested something like: "Authoring tools should be designed so that everybody can create Web content."
AA: authoring tools may be used by majority of people, but some may be used by people creating much more complex sites and you may require the talent to make sophisticated sites or applications. Concerned about saying that all Authoring Tools should allow everybody...
SLH: the whole section is too lofty in my opinion.
DS: Andrew's opinion is good, but also agrees with what Shawn is saying. We are really just talking about is it accessible.
WD: "Accessibility means that anyone with the ability has the possibility of using it."
JB: an interesting challenge statement!
Add a much more direct statement(s): [Judy captured for the note to ATAG]
"3.1.2 Checkpoint Priorities"
WD: agrees that the ATAG definitions were not clear and had to be read a few times.
WL: problem is that it is elaborate, but if you use the priorities you understand that it is confusing but can't figure out how to make the complex relationship more understandable.
SLH: she is willing to help look at this because it was really numbing.
JB: agrees it is overwhelming and difficult to read. Could be an area where we comment about our concern but don't necessarily offer specific suggestion, but offer to help. Any other discussion? Any general reactions?
AA: likes Pasquale's suggestion of regular vs. relative. In the introduction, defining the two types is a good idea but doesn't have a good suggestion. (Also mentioned a recursive link in that section - Judy captured the technical comment).
JT: part that confuses him is checkpoint priorities for 3.1.2; what is the outcome of the different categories. Is it really just similar to what WCAG does? Needs to be linked back to the practical meaning.
JB: is there a shorter way to present Pasquale's comments.
SLH: thinks existing section is unnecessarily complex.
JB: start by saying "their intent seems clear but seems unnecessarily complex. Then add Justin's comment. Will send Shawn to help you with that part."
WD: disagrees - thinks it is necessarily complex. Thinks they should back up and take the point of view that they are defining something mathematical, what terms and concept do we mean, then get into the details. A complex method of determining conformance and thinks they are coming in too low.
JB: add something like "this needs to be explained better with better terminology"
WD: their graphic introduces the terminology before the terms are defined in the text.
JT: these terms should be defined in section 1.4.
JB: several people commented that regular vs. relative terminology should be used more (or at least defined earlier).
[Judy read back what she had captured on this topic].
AA: Pasquale's last comment (in brackets) should be included in our comment.
[There was some discussion of this that Shawn captured and will bring to ATAG when she reviews this with them.]
WD 22 Nov 2004 comments (1 of ?)
"2. use of "format" versus something like "technical specifications" ?"
SLH: Doesn't understand use of term "format".
WL: when you select "new" in an Authoring Tool a template is provided and that...
JB: should our comment be that if only experts know what this means we should suggest they find a better way of explaining it. Particularly in section 2.1. (is the "format" a DOCTYPE? XML? HTML? Markup languages? or to what? Explain to make clearer to the audience(s)) And reinforce this in glossary definition.
"3. In the success criterium, the terminology "must always conform" is
JB: take comment as is? Discussion? Objection to sending comment with others?
JB: unable to tie together all comments from last week. Proposes to wrap
up ALL comments by Monday; also submit work of Lexicon Task Force. Put them
to list by Monday morning, give us a chance to respond, and let Matt and
Jutta that our comments are on the way. If Shawn has further comments,
discuss with Judy offline. Any additional comments or suggestions or
JB: Appreciates detailed comments submitted by members.
- Please review and prepare to comment & discuss:
Draft of Selecting Web Accessibility Evaluation Tools
JB: Shadi had prepared a complete rewrite - jumping ahead of what we were
even talking about. Asks that people comment on the list before next meeting.
SAZ: please look at if the document is more suitable at meeting the requirements (e.g. shopping list?) If not, where are the gaps? Please don't focus on editorial comments.
[We ran out of time... this item to be brought forward to the list and next meeting]
[28 February 2005]