Gv: Gregg Vanderheiden
Cl: Chuck Letourneau
Hb: Harvey Bingham
Jk: Josh Krieger
Dd: Daniel Dardailler
Wc: Wendy Chisholm
Ag: Al Gilman
Gf: Geoff Freed
Ij: Ian Jacobs
Co: Chuck Opperman
Jw: Jason White
CmN: Charles McCathieNevile.
Gv: lets start with a quick review of Judy's note commenting on Gregg and Wendy's list of target groups and targeting PA's efforts to those things that are most important - leave discussion of things that are best in EO and ER WG's purviews. Specifically we should be concentrating on what is accessible.
Ag: plalying devil's advocate - The first briefing draws most of the issues - If the PA WG publishes a document that doesn't include all the pieces that are needed at the same time, it will draw fire for seeming to be out of context.
Cl: Judy's timeline to produce modules and examples from EO is quite short.
Hb: but we should be coordinating and tracking the efforts.
Cl: Coordination Group should be able to do that.
Ag: but they don't… at a detailed level; there needs to be direct interaction, too.
Cl: but there is also overlap in membership in the EO and PA and ER groups.
Gv: if every time a new web technology comes along we have to add 10 guidelines to cover the contingencies (that might include revisiting alt-text each time) we will have a monster. Ideally he would like to revise and combine the list down from its huge size.
Jk: Although this is not my point, I agree with Gregg here only in terms of the end result. We can have as many guidelines as we want and the size can grow with each year. However, some filtering criterion should be applied to the guidelines (i.e. "priority > n" or "relevant only to HTML 4.0 compatible browsers", etc.) in order to GENERATE a smaller list that will continue to stay small by conscious design of filtering choices.
Comment: do we say here are guidelines you need to follow because of legacy software and hardware, or are we going to just tell them to switch to modern technology.
Gv: Generalizing the guidelines - a lot of what we have are strategies and we should separate true guidelines.
Hb: Lets use the term techniques rather than strategies. Also, would like 8.3 and .htm naming convention included as a guideline.
Jk: this is a great example of a legacy problem.
Gv: this is something we ought to pass to the ER or UA to provide better download capabilities. Maybe we could add as a "nice to do to increase access".
Dd: wouldn't really like to see this sort of thing in a W3C sanctioned document.
Gv: in the tool area we should look at user tools as well as author tools.
Jk: but authors might want to hear about it. Our job should be to say what the guidelines are, and ER should rate the priority. We shouldn't preclude mentioning things.
Gv: we need one document.
Jk: issues on rating system: we now have required / recommended and we must divorce them from the guidelines. .
GV: suggested that perhaps we should move away from the current defined "required" and 'recommended" and move to priority levels. This would cause us to lose some contextual information but would allow us to return to stating what makes a page accessible and leave the "requiring" to another group like ER or someone. Our current approach kind of does the ER decisions.
Dd: maybe we could add metadata to each guideline and use the CAST example to filter what you need. We still need to provide a priority for users of the guidelines. We must care that as a W3C product, it provides useful content, and in his opinion, that is some indication of priority.
Jk: what you are saying is we need in addition to the guidelines, we would need a set of metadata that is germane to our work.
Ag: a link to a description of the failure mode is valuable: if you don't do this, this will happen.
Dd: agrees - a guideline, a priority, a rationale.
Gv: ok, we need a Guideline, a priority, some strategies/techniques for addressing the guideline and some metadata such as 'what is the consequence' what browsers are affected, today or tomorrow, etc.
Ag: sounded like Dd said the recommendations from W3C must communicate priorities but Gv said each guideline has a priority associated with it. Thinks there are two different ideas at work here.
Ij: sound like something we were doing in the UA guidelines to produce a general list of principles. There were seven of them.
Cl: Kynn Bartlett also did a 6 principles document.
Gv: the table also lists 8 principles. Are these the sort of things Ag means?
Dd: agrees with Josh that we use some XML program to deliver guidelines.
Ag: what we have now are just categorization schemes. .
Gv: thinks we may have that by separating techniques from guidelines.
Gv: talked about the importance of individual prioritization as well as overarching prioritization.
Ag: doesn't believe we can prioritize the guidelines without comparing them to a site.
Dd: wants a guideline that includes priority levels - because that is what the end user wants.
Check the HTML 4.0 WAI home page.
Gv: 1. Is it consensus we need a priority for each guideline?.
Jk: yes, with qualifications - The direction I'm coming from is to try and start with a set of actual information, the accessibility issues themselves, and then gradually associating more metadata with the issues to help order them for particular needs. We can easily attach a rating. The trouble is there are multiple rating schemes and which one is better? It all depends on what you're looking for. For example, I can think of three alternate ratings right of the top of my head: 1. Severity of error, 2. Ease of fixing, 3. audience (blind, deaf, etc.). Which do you choose? We are implicitly choosing 1 by a recommended/required or n-level rating scheme. As Greg mentioned in the call, these ratings may further change over time. So in some way, the best conceptual framework is to view the accessibility issues on one side and a rating system on the other side which applies to these issues. When we prepare the final document (or potentially more than one doc) we can use a particular rating scheme (which might end up removing some of the guidelines), but our choice of which rating scheme to apply is more a policy issue than anything else and should be treated as a separate from the factual information of what is accessible and how to fix it. .
Gv: It might be useful if priorities are not seen as concretely attached to the guidelines so that the priorities could be rearranged for other applications or as technology change.
Ag: dissents: not _required_ to have a priority_per_guideline, as it would also meet user needs to have three lists: priorities, guidelines, and techniques. The guidelines could be more concrete than the priorities, and the techniques more concrete than the guidelines.
Co: but isn't GL supposed to give and rate guidelines.
Jw: working from the general to the particular is a good idea. Therefore has found it difficult to classify in the two tier systems. Also has trouble with past present and future and we should indicate why those strictures are in place and let the user decide whether the technology has moved ahead enough to implement a certain guideline.
Dd: there is an absolute requirement for instructions or a common requirement that is universal in Web design - worries that it will be too complex if we have to take into account the individual needs of every page designer.
Jw: we should look at the guidelines in the light of promoting multi-modal device independent web pages, that would be a worthwhile effort.
2: do we like the idea of combining different techniques under broader categories?.
Ag: linking and site integrity should be on the list too.
Co: concerns about putting too much stuff in on navigation as a high level requirement - it is better as a general good design practice.
3: Adding rationale, and or metadata and or failure modes?.
4: Priorities be less tightly attached: something like: "the current priority for the item is…".
Jw: likes the idea of accessibility vs. usability as long as the concepts were clearly defined. .
Jk: pressing issue in his mind is the metadata and would like to see a discussion in the list what metadata we would like to see.
Co: accessibility is usability in his mind, and people want to know what the top ten are, things like navigation should be in the document, but separated from "accessibility".
Wednesday, June 17, same time. This would make it
06:00 AM Thursday June 18 in Melbourne AU,
11:00 PM Wednesday in Greece,
10:00 PM in France,
09:00 PM in the UK,
04:00 PM in Ottawa/Boston,
03:00 PM in Wisconsin,
02:00 PM in Denver, if anyone is happens to be there, and
01:00 PM in Redmond/Los Angeles.
Please look at table and make comments or additions as appropriate?
Please look at the 9 (or more) super principles and discuss?
What metadata would go with the guidelines?
Think about priorities.
Meeting ended approx: 5:45 PM EDT.