In the room: Michael Cooper, Gez Lemon, Takayuki Watanabe, Makoto Ueki, Alistair Garrison, Don Evans (19, 20, 22), Becky Gibson, Andi Snow-Weaver, Ben Caldwell, Tom Croucher, Matt May, Kerstin Goldsmith, Gregg Vanderheiden (21, 22), Yvette Hoitink (21, 22), Wendy Chisholm (19, 21, 22)
On the phone: John Slatin, David MacDonald, Bengt Farre, Mike Barta (19, 20?), Jenae Andershonis (20), Chris Ridpath (20)
The recent internal Working Drafts of Client-side Scripting Techniques for WCAG 2.0 stimulated discussion of, "does content with scripts need to provide all functionality in an alternative manner?" [refer to Robert Fentress' email, and issue 1073]. We continue to struggle with providing information that addresses the shortcomings in today's browsers and assistive technologies while encouraging movement towards future targets. We wrestle with who has the responsibility to bridge the shortfall, how a temporary bridge may decrease the likelihood of a permanent bridge, and what happens to the users in the meantime. In WCAG 1.0 we created the "until user agents..." clause to future-proof the guidelines. However, it is a moving target and not testable. During WCAG 2.0 development, we have leaned towards the concept of "baseline" without finding an approach that resolves all of the issues. At the face-to-face we began to consider using conformance to UAAG 1.0 as a baseline. The following is an outline of the discussions from the face-to-face:
After the first two days, we were stalled on the baseline discussion and decided to categorize each HTML and client-side scripting technique using WCAG 1.0 priorities. We've been working "top down" - taking a success criteria and trying to write techniques for it. The result is that that low priority techniques often map to Level 1 success criteria. We decided to disregard the mapping to WCAG 2.0 success criteria and to focus on documenting all of the techniques needed to use a technology accessibly and then map techniques to success criteria. We concluded that if we work "bottom up" for a while, checklists will naturally evolve.
Detail from sorting HTML and scripting Techniques
We broke into 3 groups to brainstorm ideas for techniques. 2 of the groups found it difficult to progress until the baseline issue had been resolved. One group created a list of 10 possible techniques. This led into a discussion of the purpose, usability, and level of detail in General techniques. Detailed list of issues and techniques from General techniques discussion
We need resolution of the baseline issue so that we can determine what techniques to provide for "usable with out" and testing results.
Our discussion of the JIS comments led back to the main topic of the meeting - baseline - although we focused on the language and culture issues since Takayuki and Makoto were present.
We discussed assistive technologies used in Japan and that the Java accessibility bridge support is minimal or non-existent. The point was raised again that assistive technologies in other countries lack support and assistive technologies are not available in all languages, then we need to address who takes the responsibility for the shortfall.
WAC summarized major points of presentation, Metadata for Accessibility Adaptation, at the Workshop on Metadata for Content Adaptation. Authored units can be aggregated and transformations can occur through the pipeline, but what is delivered to the user agent is a delivery unit. The client can choose additional transformations (whether on client or server) but those transformations (once in user/client space) are delivery units. The result of the client transformations is a perceivable unit. @@Yvette's flow diagram
At the July face-to-face, Andi created a prototype to make the WCAG 2.0 suite of materials more usable and afterwards Becky converted it to HTML. Shawn created a prototype based on WAI site redesign work and on our prototype from july f2f:
While the prototype could be adopted as the design of the WCAG 2.0 suite of materials, we don't expect (although we wish) that the normative documents would be similar. However, we can't use this type of navigation on a normative document if the hierarchical navigation is likely to change as informative documents (Techniques) change. Therefore, we are likely to have the monolithic normative reference and the usable informative reference in a form similar to the WAI site redesign.
Also discussed Interdependent Components of Web Accessibility - the image and text explain how the user, browser, assistive technologies, content developers, and development tools fit together -- and how when one piece is broken, it can all break. it also shows the chicken and egg issue.
Wendy presented a proposal for combined Guideline 1.1 and 1.2 to address many of the Guideline 1.2 issues. Issues and discussion:
guidelines assignments are in 14 October's minutes
Suggestions for completing issues summaries:
We disucssed the direction we are headed with regard to test suites. One of the primary needs that came out of that is getting some help with coming up with test suite information for techs other than HTML.
Euroaccessibility is working on testable assertions and mapping WCAG 2.0 techniques to WCAG 1.0. This work should help us:
We had been aiming to publish public Working Drafts of the suite of documents on 3 November 2004. However, we need to allow Ben and Matt time to complete their analysis of UAAG 1.0 so that we may include a summary and questions about future direction in the Introduction to WCAG 2.0. Therefore we will aim to publish 19 November, otherwise we will wait until January (due to publishing moratoria and holidays).
There was concern that there have not been enough substantial changes to the documents to warrant publishing new drafts, however the list is more extensive than people realized: we have the Overview of WCAG 2.0 in place, Client-side Scripting Techniques for WCAG 2.0 will be a first Public Working Draft, changes to conformance, 1.1, 1.2 (hopefully), and others. The baseline issue alone is significant.
When looking at disability access we need to consider all people with disabilities. If the only way to access something requires that they purchase $1200 worth of additional technology, then only those with additional resources will be able to access the content. Thus, the cost of our baseline technologies needs to be taken into account so that all people with disabilities, including those with limited means can access Web content.
Also, we ought to consider technologies that everyone uses that cost additional resources or require additional tools. If we choose a baseline that's too high (i.e., the technology is not widely supported), people who do not have the technology (whether they have disabilities or not) will not be able to access the content. Examples:
Our assumptions are different from assumptions of people in developing countries - for example, English screen readers are more advanced than Korean. There is an additional cost for most assistive technologies although free, opensource tools, like Gnopernicus, are under development.
A public Web site and an internal intranet have different requirements and therefore different baselines. It is more possible to control or know the tools used in an intranet; not so with a public Web site.
Jason proposed a recipe. A recipe could allow us to say, "If you're providing a corporate intranet, here is a baseline you might be comfortable with." A recipe would give guidance about how to construct a baseline based on knowledge of the corporate environment the intranet is being developed in. However, if you do not know the user's environment you can't say, "use another browser." We need a balance between responsibility of the author and the user agent. We need to provide authors with guidance about how far back to develop to. A recipe should land authors post-Jaws 3.7, i.e., to a point where assistsive technologies became reasonably intelligent, so that authors do not need to know all of the nuances of the various assistive technologies. It might be that a baseline for public content is different from internal intranets.
[These notes were posted in IRC by Michael. They are the result of a discussion between Michael, Kerstin, Alex, and Andi ??. There was no discussion of this proposal and it does not represent consensus of the WCAG WG. It is included for archival purposes.]
Reasonable Baselines: The concept of baselines necessarily means that not all user agents meet the requirements expected by the baseline. With most baselines, there will be some user agents used by people with disabilities that cannot render the site effectively. Although authors may choose to use any set of technologies that match the baseline criteria, they should choose technologies for which user agent support is widespread in their target audience.
Fallbacks: To maximize accessibility, site implementation should take into account non-support for baseline technologies and provide fallback features when practical. Although not required for WCAG 2.0 conformance, this practice will increase the reach of the site.
Baseline criteria: A technology or document format must be capable of being rendered by available user agents in a manner consistent with WCAG 2.0.
Baseline: A set of technologies that meet the baseline criteria and are required for users to access the features of a site. Technologies that do not meet the baseline criteria are not part of the baseline and are subject to the WCAG 2.0 requirement to provide equivalent alternatives.
In additional to concept of baseline, an org can choose a baseline and can do so according to a recipe that we can develop
Suggested baseline (for most organizations):
- Plain text
- HTML 4.0 or XHTML 1.0
- CSS 2.0
- ECMAScript (version?)
- SMIL (?)
The following technologies are known to provide accessibility features but are not sufficiently supported by user agents and should be excluded from the baseline. In the future these technologies may become part of the recommended baseline. Provide equivalent alternatives when using these technologies:
- Flash (support is limited to the Windows platform) [QUESTION: CAN THE W3C RECOMMENDED BASELINE INCLUDE PROPRIETARY TECHNOLOGIES?]
- PDF (? - support is limited to the Windows platform?)
- SVG (support is not widespread)
- MPEG/Quicktime/Real/AVI (accessibility features exist but are not sufficiently standardized or universally supported [note SMIL is one method of providing alternatives, so these formats can be used in combination with SMIL])
- Java (accessibility features exist, but VM?s capable of using them are not sufficiently widely distributed)
The following technologies do not provide accessibility features and are not capable of being meaningfully transformed by user agents:
- Images (gif/jpeg/png/etc.)
- Audio-only formats (.au, .aiff, etc.)
- Director / Shockwave
If it is a W3C technology, such as HTML, then W3C is responsible to make it accessible. Do we ceed to reinstate the provision that authors need to use technologies with accessibility features? Is the W3C also responsible for ensuring user agents support accessibility features of a technology? [related: UAAG 1.0 Checkpoint 8.1 - Implement accessibility features (P1)]
Baseline is a policy issue, although our assumptions about support are built into the guidelines and success criteria. For example, we assume that a user who can not see the content has a tool (a screen reader, braille display, keyboard) and that the content author does not need to make the content self-voicing. Therefore, can the guidelines make an assumption of baseline and policy makers can be more restrictive as necessary? Remember that this might not be a country-by-country policy because some countries, such as China, have many industrial zones that might have different policies. However, this creates a problem for authors. If one country says, "scripts are ok" and another says "scripts are not ok" then the author has two baselines to meet. If we can create a way for authors to state their baseline and provide guidance to create a reasonable baseline.
We don't want the same baseline for WCAG 2.0 5 years from now.
don't we need a target baseline assumption in order to write the guidelines?techniques are heavily dependent on baselines
example assumptions: text is totally inaccessible to someone who is blind unless it is read to them by something. assuming user agent can render it in a form that makes it accessible to users who are blind because part of our population is blind and doesn't read Braille, we are assuming that some technology exists that can render it in audio another assumption is that all multimedia players can display closed captions
caught up in whether or not the baseline is something that developers target or whether they are built in assumptions in the guidelines
lot of discussion brought us to thinking about techniques in bottoms up approach and then see if it works with the guidelines.
if doesn't work, then determine if problem is with the technique or the guideline
baseline could be one of three things:
believes the baseline is for the author and the checklists. The guidelines should be agnostic to a particular baseline but not to the concept of a baseline
can we create a formula that will be robut enough to last over time?
If we create a baseline, aren't we banning technologies that are not on the list?
Matt reported that: major browsers are 90%+ the way there. The remaining 10% is different for each browser. ie, opera, mozilla are substantially compatable with UAAG. It's either they are mostly complete, or are missing sections. All of them are aware of UAAG and are intergrating in successive version. There is still not a browser that conforms completely to HTML 4.01, the browsers don't do things in lots of little ways. The other W3C specifications are "conform or not," they don't have A, AA, AAA. Matrix of conformance results for 8 browsers.
Looking at the test suite, on UAAG 1.0 Checkpoint 1.1 there is not a complete implementation listed. However, that one checkpoint has 22 different tests. For example, IE satisfies all but 2 tests: access key can't actuate a label and checkboxes was only partially implemented to our standard.
Could assume users will have something that meets UAAG and go push vendors to support UAAG. However, not reasonable to assume the latest version of XP and Jaws - that sets the bar too high. Could set the baseline at what is available in a user agent that is below a certain cost.
baseline is what technologies user agents can handle. question is what technologies do user agents support. what is it reasonable to assume that users can get
is there a difference between what technologies a WCAG baseline is written to and a baseline that authors declare?
in Guatemala - using IE 5 and 6, have JAWS 3.7 in Spanish. except for languages for which there is no assistive technology, everybody seems to be fairly current consumers may not own individually but have access to AT centers
proposal: pick a year(s) and geo region(s) for user agent and asst tech development (e.g., Americas, Europe, Japan, 1998+ = IE5,6, etc.) pick a list of specs to conform to (e.g., HTML 4.01, CSS Level 2, etc.), list exceptions to specs (e.g., yes - embed, no - accesskey), pick audience (e.g., all web, private intranet).
Level 1 should only be concerned with technical requirements, Level 2 can be concerned with economic requirements
How would the above proposal help with techniques? don't understand how you could write techniques that are dependent on different baselines in different regions.
checklists can change over time if it keeps getting easier for authors. companies will not create more stringent rules for themselves because then they have to follow them in order to be ISO 9000 compliant. will have to answer how the checklists can be non-normative and change over time but be the basis for determining compliance with the guidelines which are normative
[notes were sparse. not sure summarized correctly]
We broke into 2 groups to look at the issue.
Group 1 looked at home page reader report for UAAG 1.0.
there were 2 items: 1.2 and 2.3 (?)
looked like a baseline browser that was close to uaag could be used as a reference design.
"8.2 conform to w3c recs or non-w3c specs that enable creation of content to wcag 1.0" some adjustment needed, but not sure what to do about uaag if it will never be revised, although it could be published as an edited rec.
Group 2 explored several pieces, main idea was that the baseline would be set on user's requirements (that's what drives the baseline). The developers will want to know what tech pwd will be accessing the site with. if you are told to produce a site, you'll want to know what people are usin.g. however, not possible to state what people will be using, except in some cases like sweden where they give out the asst. technologies. you could end up with content that works well for people in sweden but not for people with other asst tech. it forces you to come up with a generic browser specification to design to. which leads you clearly to uaag
the other advantage is with a specification like that you can use it to corral the thinking on the technjiqeus and work within something.(in terms of bottom up approach) by framing your thinking, can provide better feedback to the guidelines. take the whole thing and work with it in the perfect world, by the time people are adopting wcag 2.0, that world is more likely to exist. by raising the bar, it encourages people to achieve that standard within the next period of time.
we're not arguing with the user agent manufactures, we'll be arguing with authors
if we create a gap, the users will fall into it.
not convinced that we need a baseline. why can't we aim for standards -- that are written with interoperability in mind -- and go forward from there?
we are never saying 'there is nothing that meets this' -- in reality we are already saying 'there are ua's that meet only 90% and we are working on. We should take the energy that we use debating these issues and developing work-around techniques to instead push user agent and assistive technology developers towards finishing off the last little bit.
In Group 2 we discussed that WCAG 2.0 will not be out until 2nd or 3rd quarter next year which gives another cycle of development for the user agent developers. We've been talking about scripting (and whether it should be included in the baseline) and uaag adresses scripting well. Also, dont forget that WCAG 1.0 still exists and can help with the gap before wcag 2.0 is adopted.
aren't there some things in scripting we still dont even know how to make accessible? there is a dhtml roadmap to get this fixed. there aren't enough sematnics at the moment but the PFWG is working with the HTML group to resolve this
UAAG 1.0 6.2 and 6.3 cover scripting appropriately wrt the roadmap: http://www.w3.org/TR/UAAG10/guidelines.html#tech-dom-access-api
http://www.w3.org/TR/UAAG10/guidelines.html#tech-content-access-api
While we are worried about a gap, people will also be worried if we dont move forward. we cant lower our standards which will leave people in the cold as wel. lyh rather have a gap in the next 2 years rather than lower our standards that might last past that. We need to future proof. a temporary bridge discourages a permanent bridge
concerned with using a standard and then taking a 'tiny bit' off to correct, because you end up with until user agents, again!
what if in three years those things still aren't done? if it's not there in 3 years, noone will be able to sell accessible solutions, and courtcases and/or enforcement will abound and force solutions.
we need to go back on a more thorough analysis and look at priorities of things not supports, and how substantial those issues are. would be great to have UAAG as the target and have industry meet it.
we should 'warn' the UA developers about this idea to give them warm up time. asap (our next public draft?) send specific request for review to the UAWG and AC reps of organizations who build browsers
what happens if noone implements in 3 years? well, we will be in the same situation, where developers are getting around the problems -- we just don't want to have to constantly adapt to the whims of industry
moz are working with UAWG on a week by week basis, and Matt is meeting MS in a couple of weeks. we have people comming to us to talk about UAAG . we don't have something that doesn't meet 100% of HTML 4.01 7 years later if they don't meet some small point is that the end of the world for accessiblity? no if we use UAAG as a baseline we have to be worried about holes. there aren't any really gaping holes in any of the major browsers at the momemt. We are also in contact with the assistive technology developers. aside from the screen reader side, apple are also working on browsers. they are comming a long way in safari and thats part of UAAG too.
UAAG is a good baseline, how much does that mean that authors need to know about AT and UA? I want to make sure we aren't going to force content developers to read and understand UAAG. authors shouldn't have to worry about UAAG - though _we_ will most certainly have to, to make sure everything fits together properly
Clarify, what would UAAG requrie for technologies with no UA that meet UAAG?
what role does cost of user agents play in baseline discussion?
can checklists have a baseline that is independent of guidelines that would change over time?
ACTION: ben and matt - do a gap analysis of uaag implementations as relates to wcag techniques
we are assuming that AT has the resp. to support acc features, assuming resp. does not belong with content dev's.
we do have the question that if we assume that the world is only as good as it is today, then loadis on author
if we assume ideal, everyone has to do their own thing, if anyone falls down, then users fall in the bottom of the gully
interim techniques? no. concern that it could end up in success criteria or legislated in some way?
no, even if it were a note -- if we set up a "how you bridge the gap" people will interpret W3C as saying "you should do this"
anything with w3c will be taken as endorsement. when you put "w3c" on it, even if it is in techniques....we have found that anything related to guidelines are looked at as "THE way to do it." fine to make the analysis, but our job is to say, "you have html here is what you have to make it accessible to user agents that are doing what they are supposed to be doing"
concern that if we do not advocate STRONGLY "the right way" noone will see the need to get there however, also concerned about present day accessibility.
if we document the gap and link to good resource sites then we will go a lot of the way to helping developers fix the gap
wcag 2.0 is future support with uaag compliant browser, with strong message from w3c as rec, wag 1.0 is for temp
until user agents...use wcag 1.0. :) we can update the wcag 1.0 techniques. probably implies need to publish edited rec"
one of the things we are doing with 2.0 is us disassociating ourselves with the problems
wcag 1.0 could cover the gap. what about contradictions in wcag 1.0 and wcag 2.0? could say which one to choose, but not that you must do both.
an interesting solution is to examine if wcag 1.0 meets all of the needs that we have. those countries could say, "for materials prepared for our consituents..." we all need to be looking at wcag 1.0, especially internationally to see if it addresses the issues."
the gap analysis is good, but why would we assume that if there is a gap then authors need to do it. if the w3c identifies the gap, and puts it into author's lap, then it might/will get into legislation as "must" not "may":
Agree that if w3c's emphasizes that the opinion of the wg is that the resp. is on the ua however, we don't want to leave the users in the lurch.
I'm hoping the Guidelines are generic enough that we don't have to get tripped in the technical shortcomings of the environment. Normative. I'm hoping that we can address these problem and interim issues in the technical docs which are hopfully "flexible" (evergreen) and can adapt to the environment as it evolves.
There is quite a lot of work on WCAG 1.0 around the world - for example Alistair's work looking at 1.0 tech and mapping to 2.0 tech - which helps provide the bridge. Also, server side AT is being created by people like Lisa as well as client-side UA like WWAAC's work. if we push the market, we will see more of this developing. Knowing that work is going on could allow us to look forward and focus on our work. if needed, we can update wcag 1.0, and this might imply publishing an edited rec for 1.0. We also have 508 and JIS Guidelines that help in the interim. Let's consider how all the pieces fit together.
WCAG 1.0 and 2.0 do contradict in certain small ways at the techniques level but maybe there can be support materials (not necessarily from WCAG WG or even WAI) to help with that?
If we move in this direction, it might delay adoption, but in a healthy way. if you want wcag 2.0, then get the user agents up to snuff. help the world get up to speed so we CAN adopt 2.0. we all agree that we need to get the load off the authors to bridge the shortfull.
Of 11 success criteria, addressed 3
Categories: WCAG 1.0 priority 1, 2, or 3, option, remove/deprecate
A usability or accessibility issue or a user agent issue?
In talking about HTML techniques, we ran into an issue with using the term deprecated for techniques. The problem with our use of it is that some deprecated techniques refer to elements that are deprecated in other specs, but other times, we use it to refer to techniques we no longer want authors to use.
@@get notes from Michael
$Date: 2004/11/15 19:39:40 $