W3C logo Web Accessibility Initiative (WAI) logo > EOWG Home > EOWG Minutes

EOWG Minutes 17 September 2004 Meeting

on this page: attendees - outreach updates - Components of Web Accessibility - EOWG Deliverables - next meeting

Meeting Summary and Action Items

Action Items


agenda in e-mail list archives:



Outreach Updates

No outreach updates.

Components of Web Accessibility

Background (from agenda):

- latest version: http://www.w3.org/WAI/EO/Drafts/UCD/components
- previous version: http://www.w3.org/WAI/EO/Drafts/UCD/components-old4
- changelog: http://www.w3.org/WAI/EO/changelogs/components

note: This is still an early concept draft. We need to focus now on making sure that the information is correct and generally conveyed how we want it to be conveyed. It is not ready for a review of specific wording.

discussion questions:


JB: some comments on the list prior to the meeting. [links]. Asked Shawn to go over the draft and review the discussion questions.
SLH: reminded us of the purpose of the document - to demystify the interrelationships between guidelines and working groups and the WAI. Described this draft as a totally new vision. We want to focus today on the concept… not wordsmithing or copy editing.
JB: Likes the chicken-and-egg metaphor but is willing to reconsider given the possibility to misinterpret it (given different cultures and idioms). But, what do people think in general of this document?
SLH: does this document and its images work better than previous versions?
SAZ: better, less confusing.
WD: trouble with listing of user as one of the components but doesn't really appear.
SLH: if you have a perfectly technically accessible system but the user doesn't know how to use it the experience is inaccessible.
WD: but is that there?
SLH: We wanted to downplay that.
WD: I think it is kind of important and nothing is done with it. Maybe add a section explicitly explaining the users role in there.
SLH: We don't want to do that in this document.
HS: the first two pictures are better than in the first version, but would split browser and assistive technology pieces, and perhaps also split the authoring and evaluation tools, so to have one stage more between users and developers.
CC: but we would then have two steps and not all will have the extra step.
SAZ: thinks that would increase the complexity and thinks we shouldn't. In the second image (and others) would split the arrow to point to the browser.
SLH: in the top we have AT as a separate bullet, but not in the diagram… how important is it to increase complexity of images to be technically perfect?
Overall the graphics are definitely an improvement. But third one is confusing.
Do we want to incorporate the idea of what happens with poor user agent support.
HS: leave it out… what does it add?
[At least one other agrees to leave out second bullet and right half of the image.]
RC: thinks it should stay since user agents are still a problem. Some users may not be aware of the problem.
SLH: the concept would remain in the document, at the top, but not where.
JB: tends to agree with RC. Maybe needs MORE explanation, or we haven't landed on the right metaphor yet - the concept of compensation is an abstract of a complex explanation. Is there anything that would be more immediately understandable than "compensation". Not to disparage the image with the arrows, but maybe it's too complex.
SAZ: agrees it's an important point, but maybe that would be too much for this overview document.
HS: leave out the third picture altogether.
SAZ: the 4th and 5th explain well so agrees with HS.
SLH: comfortable with modifying image 3 but not removing it.
[difficult to reach consensus… some want it, some don't]
JB: would be happier to move away from "negative" of "When One Component is Weak".
HS: thinks the idea of compensation is dangerous to promote.
WD: the components are very dependent and message of what the problem is when one is weak. When we started the discussion way back the concept of "ecosystem" was good, if perhaps too complicated.
SLH: take out all sub heads - would remain Inter-dependencies Between Components, with one image (getting rid of chicken-and-egg).
HS: what if one component FAILS?
[some debate on this topic continued]
WD: A possible metaphor of a road with a huge gap with the developer having to build a bridge
JB: envisions an article focused on "the heroic we user" and the lengths they can go to go get content.
CC: looked in the thesaurus looking for words to replace "compensation": disadvantages and costs (as in the costs (efforts/burden) of fixing).
JB: is the jargon "workarounds" universally understandable.
SLH: when authoring tools don't do the job it requires much more effort from developers (or doesn't get done… that's missing).
WD: could we get away from issue of word "cost" and agree on the concept that there is some element of cost, but find a better word.
JT: first reaction to cost would be to money and a bit distracting. Likes idea of moving around as per Shawn.
RC: what about "load"? The metaphor of "weight" is a good one in Spanish. [weighting is a common metaphor in other languages as well].

The Chicken?

CC: if you explain the metaphor in text, you could leave the picture. Otherwise too confusing.
HS: kill the chicken, and the circle is not explaining the right thing. It explains there is an ongoing relationship between all the components - pictures 1 and 2 explain the right thing with the discrete lines, but doesn't see the relation as a circle between all the components.
[There was extended discussion about the visual and conceptual lines, circles, arrows, users and developers that was difficult (for the scribe) to describe in text.]
[Shawn should have enough new ideas to try some redesign]

Guidelines for Components

[any reactions?]
JB: really confused by this one.
HS: Henk also confused. Earlier versions were better where guidelines were foundations (at the bottom of the triangle).
[there followed various ideas of how to redraw the image]
SLH: proposed a redesign of the image to better show the key relationship.

EOWG Deliverables

Background (from agenda):

- review for quarterly updating:


JB: We are most of way through 3rd quarter, but 2nd quarter stuff is still on-top and she hoped we could wrap up the 2nd quarter. We usually do this review in two passes, first gathering comment then later review proposed changes. Concerned about lack of closure on some almost-finished documents (e.g. standards harmonization).

2nd Quarter

1. (Business Case) and 3. (Harmonization) are closest to completion, just needing final off-group edits.
2. (How PWD Use the Web): still some change log changes to discuss.
4. (WAI Web site redesign) - ongoing
5. (Madrid):Still more to do.
6. (Paris): Done
7. (Introductory pages)… one complete, most of rest are ready for review
8. (Glossary): more to do.
9: (Evaluation resource): more to do.
10: (Curriculum update): still pending.
11, 12. ?

3nd Quarter

JB: should pending items from 2nd quarter be priorities for 3rd quarter completions?

Text-only note?

JB: Concerned about text-only being an effective solution for accessibility - much marketing going on about this and is thinking about a staff-note or some other vehicle to address it.
SLH: provided some more background
JB: reminded us that the text "myth" has been hanging around since the beginning and really needs to be addressed more formally. Mentioned "Inaccessibility of Visually-Oriented Anti-Robot Tests: Problems and Alternatives - W3C Working Draft 5 November 2003" [http://www.w3.org/TR/turingtest/] [as an example of a note-track document.]
HS: agrees this should be a priority.
[others seem to agree, and it seems the note-track is a good idea]

Action: Judy and Shawn will discuss the third-quarter items and get back to us for the next meeting.

Next Meeting

24 September 2004

Last updated on $Date: 2005/08/18 14:42:35 $ by $Author: jthorp $