Minutes from 19-22 October WCAG WG F2F


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)


"Baseline" - collection of issues and next steps

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:

  1. General discussion and collection of issues
    1. It's a "chicken and egg" problem
    2. How do we address economic and world-wide adoption issues?
    3. How do we define "Web content?" Are intranets covered?
    4. Can we create a "recipe" that allows people to construct their own baseline?
    5. Who is responsible for the accessibility of a technology?
    6. Policy-related issues
    7. If we create a "recipe" for baseline, is the purpose for authors to create their own or for us to create a "universal" baseline?
    8. Does excluding a technology from the baseline effectively ban it?
  2. UAAG as possible baseline
    1. Which browsers conform to UAAG?
    2. Is baseline determined by technologies or user agents?
    3. UAAG shortfall analysis
    4. Pros and cons of interim techniques

Next steps

  1. Analyze effect of adopting UAAG baseline: how would that effect advice in techniques? how would it effect users? how many existing techniques would be considered "repair" techniques?
  2. If the analysis is favorable, determine approach for referencing UAAG
  3. Develop language-specific checklist items (refer to JIS discussion)

Straw poll to determine priority of individual techniques

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

Next steps

  1. redo analysis after next public WD
  2. analyze how UAAG baseline would effect advice in techniques

General 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


  1. Do general techniques for each criterion make the guidelines more difficult to interpret? The first two layers (guidelines and general techniques) are not technology specific and could make it difficult for authors to find needed information.
  2. Should we move all or some of the general techniques information into the guidelines document?
  3. How do we address techniques for out-of-specification technologies (ex. embed)?
  4. Should some of the general techniques become success criteria?
  5. General techniques are often HTML-specific. Is it possible to always illustrate a point without a technology-specific example?
  6. Should general techniques be as testable as technology-specific techniques? Is our standard for human testability rigorous enough? (compare to EuroAccessibility)
  7. Are the general techniques descriptions or are they techniques?
  8. Printed, we currently have over 200 pages of content. The idea of an "O'Reilly version" of the guidelines was brought up again (originally proposed by Matt 7 June 2001).
  9. We need volunteers to help draft additional general techniques.


CSS Techniques

We need resolution of the baseline issue so that we can determine what techniques to provide for "usable with out" and testing results.

Client-side Script techniques

  1. Is the purpose of the client-side scripting techniques to describe how to use JavaScript in an accessible way or to avoid using JavaScript or to describe how JavaScript can degrade?
    The answer depends on baseline resolution. Related questions and proposals:
    1. ISSUE: What would go into the <noscript> element for a Web application?
    2. PROPOSAL: If the script is decorative or if the functionality can be provided via another mechanism, then the noscript element doesn't need to do anything. [In this case, does the noscript element need to exist?]
    3. PROPOSAL: general rule: only remove stuff from the screen with scripts, don't add stuff? [UI designers are not likely to accept this]
    4. PROPOSAL: <noscript> should not be required if the page works with scripts disabled and you don't lose any content or functionality.
    5. PROPOSAL: Create a list of scenarios where JavaScript is a problem [could be the most valuable thing to do today.]
  2. How does the WCAG work on client-side scripting techniques relate to UAWG and PFWG work on DHTML roadmap?
    There are many DHTML menuing systems, some of which work with assistive technologies and some that don't. WCAG WG could test them and specify which work rather than describing how to write one from scratch.
  3. What about techniques that combine technologies?
    HTML, CSS, and script techniques are interrelated (in the real world), yet our techniques address them separately.
  4. What about other types of scripts?
    We are constrained to address W3C and open technologies. Technically, we are providing techniques for ECMA script. The concepts should also apply to VB script. Bind events through the DOM rather than using embedded event handlers. Eventually, users can apply their own scripts to a site (external scripts) and cross-site scripting.

JIS comments

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.

Authored unit, delivery unit, perceivable unit

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



Design of WCAG 2.0 materials

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.


Proposal for combination of Guidelines 1.1 and 1.2

Wendy presented a proposal for combined Guideline 1.1 and 1.2 to address many of the Guideline 1.2 issues. Issues and discussion:


Guideline assignments

guidelines assignments are in 14 October's minutes

Suggestions for completing issues summaries:

  1. When summarizing issues, please propose resolutions to open issues.
  2. If an issue has been resolved on the mailing list, add the link to the mailing list post to the Bugzilla issue and mark the issue as "pending."
  3. Divide summaries into
  4. Send the complete proposed text of the guideline (changes included) followed by a list of the proposed changes.

Test suites and checklists

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:

  1. Provide good transition support materials
  2. Check for (and address) conflicts between WCAG 1.0 and WCAG 2.0

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.

Detailed list of issues from the baseline discussion

It's a "chicken and egg" problem

  1. some features are not supported in all user agents
  2. traditionally, wcag requires alternatives to be provided
  3. if not required (because authors are using alternatives), then user agents developers do not see reason to implement support for a given element, attribute, or other feature.
  4. we don't want to ban a technology, because it will hurt innovation or people will innovate anyway and accessibility will be left behind.
  5. we don't want to require alternatives if the technology is widely supported by user agents.
  6. javascript/ecmascript and flash are the common examples
  7. who's responsible? content author or user agent?
    Interdependent Components of Web Accessibility illustrates these issues.

How do we address economic and world-wide adoption issues?

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.

How do we define "Web content?" Are intranets covered?

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.

Can we create a "recipe" that allows people to construct their own baseline?

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.

Proposal from the Baseline discussion

[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):

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:

The following technologies do not provide accessibility features and are not capable of being meaningfully transformed by user agents:

Who is responsible for the accessibility of a technology?

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)]

Policy-related issues

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.

If we create a "recipe" for baseline, is the purpose for authors to create their own or for us to create a "universal" 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:

  1. what we use to write the guidelines
  2. what a developer uses to build accessible content
  3. what would be used to guide the evolution of the checklists

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?

Does excluding a technology from the baseline effectively ban it?

If we create a baseline, aren't we banning technologies that are not on the list?

UAAG as possible baseline

Which browsers conform to UAAG?

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.

Is baseline determined by technologies or user agents?

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

UAAG shortfall analysis

[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


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.

how big of an impact is the delta on ua's that don't meet 100%?

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

pros and cons of interim 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.

Detailed list of issues and techniques from General techniques discussion

Guideline 2.2 - Time limits



Guideline 2.1 - Keyboard operation


Guideline 2.5 - Avoid mistakes

Of 11 success criteria, addressed 3

Possible techniques

  1. forms - prompts, mistakes
  2. identify required items
  3. feedback on required fields, bad formatting
  4. restricted values (list boxes)
  5. way to reverse mistakes - review submission before confirmation, undo, cancel
  6. breaking up long forms into multiple steps (pages)
  7. Google example where it tries to help you with suggestions for improved spelling
  8. Visual feedback e.g., "print this page" links where you don't know if it printed or not
  9. Plain language when reporting errors
  10. Bugzilla-style help as an approach



  1. Input options known but less than 75 - why that number, and why so high?
  2. Some of this was a question of whether it should be a technique or a success criterion
  3. how does this apply to voice XML? would verification be required for each input?

Detail from sorting HTML and scripting Techniques

Categories: WCAG 1.0 priority 1, 2, or 3, option, remove/deprecate

HTML Techniques

16.4 Auto submit combo boxes

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.


Client-side Scripting Techniques

@@get notes from Michael

$Date: 2004/11/15 19:39:40 $