Web Content Accessibility Guidelines Working Group Meeting Highlights

Introduction

This is a collection of highlights from our weekly phone meetings. They are posted here to make it easy to find these for future reference. It is an attempt to capture and highlight some of the most notable ideas and discussion points addressed during the weekly phone meetings.

Related links:

• Minutes from WCAG WG meetings
• Resources and References
• Development of WCAG 2.

7 November 2002 Telecon Highlights

1. Level 3 success criteria for checkpoint 1.2
   • The presentation does not require the user to view captions and the visual presentation simultaneously in order to understand the content.
2. Checkpoint 1.1 Re-Draft.
   • 1.1 For all non-text content provide a text equivalent, or, if the content cannot be expressed in words, provide an identifying text label.
     • Level 1:
       1. Non-text content that can be expressed in words has a text equivalent explicitly associated with it.
       2. Non-text content that cannot be expressed in words has an identifying text label explicitly associated with it.
     • Level 2:
       1. If a text-equivalent has been used:
          • The text-equivalent has been reviewed and is believed to fulfil the same function as the author intended for the non-text content (i.e. it presents all of the intended information and/or achieves the same function of the non-text content)
       2. If an indentifying text label has been used:
          • The identifying text label has been reviewed and is believed to convey as much of the function and meaning of the non-text content as possible to match the authors intent.
     • Definitions
       • An identifying text label: is a text label used when a text equivalent cannot be used because the non-text content is such that it cannot be expressed in words.
         • Serves as much of the function of the non-text content as possible.
         • May contain structured content
3. Checkpoint 1.2 Issues (minimum Level)
   • Item 2 - all significant dialogue and sounds in multimedia content are captioned
   • New Item 3 - (does not replace current #3) For Web that is real-time audio-only, is not time-sensitive (e.g. not news, not emergency, etc.), and is not interactive, a transcript or other non-audio equivalent is available from the same URI.
   • [at bottom of level 1 put] NOTE: Exceptions for amateur productions etc. are not made here because they should be made in scope statements of policy setting agencies that are using these guidelines.
4. Slight rewording to fix typo and omission to exception at level 1 for checkpoint 1.2
   • exception: if content is rebroadcast from another medium or resource that complies to broadcast requirements for accessibility for the location it was broadcast, the rebroadcast satisfies the checkpoint if it complies with the other guidelines and if any existing accessibility information (such as captions or audio description) are rendered in web accessible format. (See Level 3)
   • Level 3 exception: content is rebroadcast from another medium or resource has synchronized media equivalents for all audio and visual components of time dependent presentations.

12 September 2002 Telecon Highlights

Discussions in the joint DIWG and WAIWG meeting identified 5 Candidates for collaboration:

1. Device Independence Scenario Repository (Member Space)
2. Additional authoring scenarios
3. Terminology and glossary coordination
4. Shared development of and cross-group contribution to techniques repository
5. Exploration of what constitutes the range of user interfaces and the constraints of different users and their interfaces. (e.g. What are the different types and combinations of user interface that a site is likely to see. For example,
   • "Keyboard and large display" (standard PC)
   • Pen on screen and small display” (standard PDA)
   • "Keyboard and speech out - only” (User who is Blind) )

1 August 2002 Telecon Highlights

1. Regarding criteria for determining success criteria:
   1. We decided that success criteria had to all be things that were testable. This could either be:
      1. machine testing
      2. Human testing with a high inter-rater reliability (HIRR). (i.e. most raters who understand issue and/or measure would all say the same thing.)
   2. We also decided that Levels 1 and 2 would have to be things that applied to all (types of) sites.
      • This is especially important for Level 1 – since no type of conformance could be claimed if without all level one items. And if we made it so that some sites could not reasonably meet level 1, we would be making it so that some sites could make no claims of accessibility.

2. Regarding goal statements for creating level 1,2,3, etc success criteria
   • Criteria for Level 1 Success Criteria {All of the criteria should be true}
     • Must be testable (Machine or HIRR)
     • We want to recommend that Level 1 items be done everywhere [or almost everywhere?]
       • Therefore needs to be things that can be done on every site – no exceptions unless the exception is in the success criteria.
     • Important to access – not just relatively minor usability tuning. If these aren't done – people can't access the information. (e. g. no captions)

     RATIONALE: If we make a Level 1 item that is unreachable for some sites, then they will not be able to make any claim of any kind as to access. This would greatly lower incentive to do other items. Therefore all Level 1 items need to be doable on almost all or all sites -- and doable on very large and existing sites. This is the MINIMUM. We encourage everyone to also do level 2. (and to do Level 3 wherever possible)

   • Level 2
     • Must be testable (Machine or HIRR)
     • Things that go beyond Level 1 but that can still be done on essentially all content on all sites (if designed properly)

     RATIONALE: These are things that we hope and encourage all sites to do – and want these to be doable enough that we can ask all managers to require (i.e. require Level 2 conformance) These items make sites more accessible or usable to people with disabilities and also make sites accessible to more people who particularly those who have severe problems related to this checkpoint.

   • Level 3
     • Things that are testable (Machine or HIRR) that aren't in level 1 and 2

     RATIONALE: Don’t expect these to be done on most sites. But would be done on all sites that really want to go the extra mile

   • Additional / Advisory Items
     • Things that are not testable but are good ideas to address this checkpoint (good advice)
     • Things that can't be done on all sites
     • Things that might be done to target or tune a site specifically for a disability group who needs this checkpoint

     NOTE: As you go down the levels – you will pick up more and more people who cannot use a site unless lower level items are implemented. Thus the lower levels make it easier for some people with disabilities, but they will make it possible for others, particularly with multiple or very severe disabilities.

27 June 2002 Telecon Highlights

• In preparation for publication of a public document to TR, a new internal draft (June 26) has been posted. The group is encouraged to review the new draft as we proceed toward publication to TR.
• For Checkpoint 2.1
  • Editors will reword slightly to match other checkpoints
  • Example 1 will be removed (not a good example for this checkpoint anymore)
• The graphic used in example 1 of checkpoint 1.1 will be updated so that the word "next" is no longer part of the image.

20 June 2002 Telecon Highlights

1. Regarding proposal for new checkpoint 1.5
   1. Revised success criteria at the minimum level will read,

      "Text in the content must be Unicode or sufficient information is provided so that it will be automatically mapped back to Unicode."

   2. An additional success criteria for level 2 will be added. It reads,

      "Symbols such as diacritic marks that are found in standard usage of the natural language of the content and necessary for unambiguous interpretation of words are present or another standard mechanism for disambiguation is provided."

2. Cynthia and Lisa are going to be exploring whether language translation software can already disambiguate words and could be used as part of a tool to automatically add diacritical marks.
3. Checkpoint 4.4 will be subsumed by the inclusion of the new 1.5 checkpoint.
4. The group confirmed previous decisions to rework guideline 5 according to Cynthia's proposals for the next internal draft.

13 June 2002 Telecon Highlights

1. Cynthia, Paul and Wendy's proposal for checkpoint 1.2, was reviewed with discussion focusing primarily on edits to the minimum level success criteria. A new draft of the proposal based on the discussion is available for review.
2. Gregg and Ben are working on a new checkpoint for Guideline 1 that is focused on providing information needed for unambiguous decoding of the characters and words in content. The new checkpoint will address the issue of missing vowel marks (such as in Hebrew) and will incorporate discussion of character set remapping (text must map back to (whatever international group says) character set).
3. New Issues (tracked with experimental issue tracking tool):
   • Accessible rebroadcasts
   • Character encoding
   • real-time or interactive presentation and deaf-blindness
   • checkpoint (or definition) about use of standard character set
4. (General Comment) In discussing the checkpoint 1.2 proposal, John Slatin suggested that we should avoid using language that ensures that the user can achieve the author's intention. Instead, we should say that the author has provided an equivalent that achieves the purpose of the content.

6 June 2002 Telecon Highlights

Highlights from today's telecon.

1. Regarding 4.1, the group decided that the best way to proceed would be to try to compile a list of all the ideas without discussing their assignment to any particular level. It was felt that we could have a more constructive discussion if people were first collecting all the ideas without worrying about whether they should be required for this or that or every site.
2. The group came up with the following to put into the WCAG2 draft for the TR release:
   1. 4.1 main item will be "Write as clearly and simply as is [appropriate/possible] for the purpose of the content."
   2. We have no level SC Levels
   3. We provide a partial list of ideas based on the current draft plus some items from the GL list.
   4. Include a reviewers note that says 4.1 is currently still under development. The intended form is to have a list of strategies in the informative portion. No decision has been made about what will be in the final document or if they will be in the success criteria or in the informative section has been made. (similar to checkpoint 3.1) (group agrees) --- underneath put -- A partial list of strategies for addressing 4.1 includes: [list to be based on list in current draft plus some additional items from the GL list:]
3. We will be creating a master list of all ideas related to 4.1. Ideas will be divided into 4 categories.
   1. fairly solid items
   2. items which are possible, questionable, or need work
   3. items that depend on something which does not yet exist
   4. items which address 4.1 but really are part of other checkpoints (ex. structure, markup, etc.)
4. Another highlight was Lisa's discussion of the cascading lexicon reference links in metadata. (i.e. providing a way for AT to find a pointer or list of pointers to various places where definitions for words on the page.) (e.g. references to definitions for terms that were used on the page, that are often used by the author, that are often used on the site, that are particular to this topic area, etc.)

30 May 2002 Telecon Highlights as posted to GL

Regarding Flicker

1. We felt that everything about what the author needed to do so that users could view without seizures needed to be in level 1. Level 2 might be about things that meant users wouldn't need to have fast equipment in order to be sure - but they should be able to have reasonable equip and be safe with level 1. This isn't the final word on this but a thought we wanted to be sure to capture. (another thought was that there be nothing below level 1)
2. Regarding the testing tool. Trace said it was going to explore. Also thought of having a two ended tool (idea coming from the discussion above). Two ended tool would be one that tested pages to meet a certain criterion. Then also allowed users to test their computers to see if their computers would safely display pages that met the tools page test. (e.g. if screens the met the test would flicker on their equipment because it was very slow or something - then they would know it.)
3. Thought maybe the compliance levels might be

   LEVEL 1
   Success Criteria 1 - content was not designed to flicker (or flash)in the range of 3 to 49 Hz.
   Success Criteria 2 - (reader's note: we would like to include a second criteria here which would state that a test that was conducted and the pages passed. No test or tool exists yet though. Looking into how such a test and / or tool might be designed.)

   LEVEL 2
   Success Criteria 1 - (tougher test - that would make pages pass with even slower equip. Equip might be old or just slow for other reasons)

General Comments Regarding All Checkpoints

1. As a rule, we shouldn't ask companies to guarantee that something won't happen, only to state that they did something or that something didn't happen the author tested. (based on suggestion from Matt May)

Regarding Contrast and Color

1. Suggested that instead of using ratios or percentages, we define a specific number of points or equation in RGB that could be used to determine sufficient contrast. (e.g. don't say 10 to 1 contrast. Say contrast must be xx points apart. For example "200 points apart on a 256 scale" (based on suggestion from Cynthia)
2. Is RGB the best format for making specifications? (Wendy took @@ on this to ask some experts)
3. In determining success critieria for this checkpoint, we should use scales that authors are familiar with and limit discussion of color theory to display (rather than print) technologies.

$Date: 2010/09/09 15:20:42 $