This page tracks the issues raised during the Proposed Recommendation review that the WC WG is expected to resolve prior to publication of the WC guidelines document as a Recommendation. Possible issue categories are:
If there is an issue that is not on this list, or that is misrepresented or inadequately summarized, please send your comments to w3c-wai-gl@w3.org list or contact the editor, Wendy Chisholm, at chisholm@trace.wisc.edu.
This document was last updated 28 Apr 1999.
Issue raised by: Advisory Committee (AC) member
Issue category: Bug
The CSS stylesheet attached to the proposed document contains no accessibility specific styles at all.
Add such styles to all W3C public stylesheets in general, and to the proposed document in particular.
W3C staff are in the process of resolving this issues
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Editorial/Clarification
Resolved: 13 Apr 1999
Note that this recently underwent a revision and therefore might be expected to require some editing. As noted, the reference to "synthesized speech" as requiring a "text equivalent" would not be comprehensible without further explanation.
delete reference to synthesized speech
deleted
none needed
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Editorial/Clarification
Resolved: 13 April 1999
Checkpoint 14.2 mistakenly makes reference to equivalents "to text". [Provide visual or auditory equivalents to text where they facilitate comprehension of the page.]
Edit the checkpoint to read, "Supplement text with graphic or auditory presentations where they will facilitate comprehension of a page."
none needed
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Editorial/Clarification
Resolved: 13 April 1999
The word "visual" is used to describe non-text elements, even though text is usually rendered in a visual manner.
The editors will reread the document to ensure that visual is use appropriately, especially in regards to presenting text. If something earth shattering is revealed, the editors will bring it to the discussion on Thursday.
Editor todo.
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Combine, subsume, or eliminate
Resolved: 13 April 1999
The need for text equivalents for ASCII art was cited in two checkpoints (1.1 and 1.5). [1.1 - Provide a text equivalent for every non-text element. 1.5 - Replace ASCII art with an image or explain it.]
Delete checkpoint 1.5.
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Editorial/Clarification
Resolved: 13 Apr 1999
The description of the relationship between the terms "assistive technology", "screen reader", and "user agent" is not consistent throughout the document.
The editors will reread the document to ensure that these terms are used consistently. If something difficult is revealed, the editors will bring it to the discussion on Thursday.
To be consistent w/UA guidelines, ATs and browsers are both UAs.
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Editorial/Clarification
Resolved: 13 April 1999
The guidelines document does not claim a conformance level.
[Insert logo here when available]
Issue raised by: Eric Hansen - 6 Apr 1999
Issue category: Editorial/Clarification
Resolved: 15 April 1999
The document does not say how to handle conformance ratings for inaccessible primary pages that have accessible alternative pages.
Checkpoints that may be satisfied by having an accessible alternative page say so in the checkpoint. For example, 6.3 may be satisfied either by ensuring the "page is usable when scripts, applets, or other programmatic objects are turned off or not supported" or by providing "an equivalent mechanism on an alternative accessible page." The editors will read to make sure that wherever this is the case, it is stated properly
No change required
Issue raised by: Wendy Chisholm - 2 Apr 1999
Issue category: Editorial/Clarification
Resolved: 15 April 1999
The example for 6.3 focues too much on NOSCRIPT and should highlight graceful transformation [For example, in HTML provide a text equivalent with the NOSCRIPT element or via a server-side script. Or provide a non-text equivalent (e.g., a snapshot in place of an animation, a video equivalent of an applet, etc.). For applets and programmatic objects, provide text equivalents. Refer also to guideline 1. ]
For example, when using JavaScript in an HTML document, do not use "javascript:" as the URI for a link. If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, use a server-side script instead of client-side script, or provide an alternative accessible page. An example of an alternative mechanism for an applet simulation is a video recording of someone interacting with the applet simulation. Refer also to guideline 1.
For example, ensure that links that trigger scripts work when scripts are turned off or not supported (e.g., do not use "javascript:" as the link target). If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side script instead of a client-side script, or provide an alternative accessible page as per checkpoint 11.4. Refer also to guideline 1.
Issue raised by: Wendy Chisholm - 2 Apr 1999
Issue category: Editorial/Clarification
Resolved: 15 April 1999
6.4 is device dependent - "keyboard operable". [6.4 - For scripts and applets, until user agents provide device-independent means to activate event handlers, ensure that event handlers are keyboard operable.]
reword 6.4 to read, "For scripts and applets, ensure that event handlers are device independent."
Issue raised by: Wendy Chisholm - 2 Apr 1999
Issue category: Editorial/Clarification
Resolved: 15 April 1999
in checkpoint 6.4 - are we sure that user agents will provide device-independent means to activate event handlers? Even if they do, shouldn't authors be encouraged to ensure that script and applets are written to be device independent?
Delete the phrase, "until user agents provide device-independent means to activate event handlers," from the checkpoint.
Delete "until user agents" from 6.4. [ checkpoint 6.4 now reads: "For scripts and applets, ensure that event handlers are input device-independent."]
Issue raised by: Wendy Chisholm - 2 Apr 1999
Issue category: Bug
Resolved: 15 April 1999 - See discussion on Keyboard operable vs. device independent.
The examples in 9.3 are incorrect. Currently, to work in IE and Netscape, both onFocus and onMouseOver need to be implemented to achieve the desired affect. Since a more logical, "onActivate" is really what is needed, I propose dropping this example in the Guidelines document and dealing with it in Techniques.
drop the example from guidelines, discuss in techniques.
Drop the examples.
Issue raised by: Wendy Chisholm - 2 Apr 1999
Issue category: Editorial/Clarification
Resolved: 27 April 1999
6.5 is too loosely defined. [6.5 - Provide an alternative presentation or page when the primary content is dynamic (e.g., when frame contents change, when scripts cause changes, etc.).]
The scripts and applets portion of this is handled in 6.3. Move the NOFRAMES portion to Guideline 10 [Use interim solutions] as the new 10.6 - "Until user agents are able to navigate and display multiple pages laid out in one window (as with HTML Frames), provide a means to access the pages one at a time. For example, in HTML use the NOFRAMES element with links to each frame in the frameset. [Priority 2]"
The group realizes that the scope is too broad for 6.5 but it should not go away nor should it solely discuss frames. the crux is that dynamic information that is updated without the user noticing is an issue for both frames and scripts.
Reword the checkpoint to read: Ensure that dynamic content is accessible or provide an alternative presentation or page. (e.g. NOFRAMES, ) [Priority 2]
This is different from 6.3 and 6.4 in that:
6.3 says, "when dynamic content is *not* loaded, the page must still be usable." 6.4 says, when using scripts and applets to create dynamic contents, ensure that they are input device independent. 6.5 says, when scripts, applets, or other dynamic content, such as frames, is used, ensure that the user knows when changes have taken place, or that if there are complex relationships between dynamic elements that there is a serial way to access them. for example, if it is not possible to interace with the frames with a screen reader, provide a serialized pathway through the information in NOFRAMES or provide a frames that is solely a "status" frame to help someone navigate the frames serially.
For techniques: another way to make frames accessible is to provide a "status" frame. **
Ian: We shouldn't discuss status frame since too late.
Issue raised by: Wendy Chisholm - 2 Apr 1999
Issue category: Combine, subsume, eliminate
Resolved: 15 April 1999
. It seems that checkpoint 10.2 ought to be a note for checkpoint 12.4. [10.2 - For all form controls with implicitly associated labels, ensure that the label is properly positioned. 12.4 - Associate labels explicitly with their controls.]
Reword 12.4 to read, "Associate labels explicitly with their controls. Note. when controls are not explicitly associated, ensure that the label is properly positioned. The label must immediately, ....rest of 10.2..."
Add "Until user agents" to 10.2.
Issue raised by: Wendy Chisholm, but not to the working group. (no reference)
Issue category: Combine, subsume, eliminate
Resolved: 15 April 1999
Checkpoint 3.8 is incorrect and contradicts the HTML4.0 spec [3.8 - Provide individual button controls in a form rather than simulating a set of buttons with an image map.] The idea this checkpoint is trying to convey (to avoid using server-side image maps in form input controls) is a technique of "avoid server-side image maps" (checkpoint 9.1).
Delete checkpoint 3.8 and discuss in the techniques document in the Forms section, and point to it from the Image map section.
Issue raised by: AC Member
Issue category: Editorial/Clarification
Resolved: 27 April 1999
One AC Member thought that guideline 11 almost mandated using "W3C technologies" and they thought this should be more broadly generalized to encompass "technologies and specifications arrived at through an open industry consensus process, such as W3C specifications". They also felt that renditions using proprietary technologies may be justified by business considerations and not only as a "last resort when all other solutions fail." However, they did feel that in such situations the user should be able to select an accessible rendition based on open consensus standards.
To clarify that the W3C technologies are specified because of their unique characteristics such as internal early review for accessibility and built in accessibility considerations at the design stage and before approval in addition to the open industry consensus process.
We would also clarify that in cases where proprietary or inaccessible technologies must be used (and these would include good business cases) that it was OK as long as an accessible alternative was provided. However, separate but equal, should only be used where there is a good reason.
PUT RATIONALE IN FIRST PARAGRAPH OF 11 - Clarify the unique aspects of W3C process, e.g. internal coordination for accessibility expertise, review, & approval of all W3C specs. Modifications to rationale are:
The current guidelines recommend W3C technologies (e.g., HTML, CSS, etc.) for several reasons: * W3C technologies include "built-in" accessibility features. * W3C specifications undergo early review to ensure that accessibility issues are considered during the design phase. * W3C specifications are developed in an open, industry consensus process. Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard Web access or screen reading tools. Avoiding non-W3C and non-standard features (proprietary elements, attributes, properties, and extensions) will tend to make pages more accessible to more people using a wider variety of hardware and software. When proprietary or inaccessible technologies must be used, equivalent accessible pages must be provided.
CHANGE 11.1 AS FOLLOWS
11.1 Use W3C technologies and use the latest versions when they are AVAILABLE AND APPROPRIATE. [Priority 2] (See also 11.4)
Ian counterproposes (but has not edited the document to read): "Give preference to applicable W3C technologies and use the latest versions when they are supported."
Refer to the list of references for information about where to find the latest W3C specifications. [Done]
Techniques for checkpoint 11.1
Issue raised by: AC Member
Issue category: Editorial/Clarification
Resolved: 27 April 1999
The AC Member felt that although Guideline 6 reads: "Ensure that pages featuring new technologies transform gracefully", it was not necessarily clear enough that forms were a particular problem. They suggested adding either a specific guideline about "Forms", a checkpoint (6.6), or at least refer to "Forms" explicitly in 6.3 and 6.4 and provide techniques for them.
The reason for this concern was that many browsers do not support forms or the form submission techniques depend on using Java or Javascripts .. etc.
Furthermore, many people are unaware of the forms being new technologies.
To follow the AC Member's recommendation and include Forms in an example in 6.3. The Java/ Javascript would then be covered in 6.3 and be easier to spot. [Todo by editors]
none needed
Issue raised by: AC Member
Issue category: Editorial/Clarification
Resolved: 27 April 1999
An AC Member suggested that we should provide hot links from the techniques document to the Guidelines document. They further suggested that this can be implemented in a fashion similar to the links provided from the guidelines to the techniques using sections. i.e. a technique for a checkpoint numbered "n" may return a reader to the Guidelines document checkpoint "n".
The anchors are in the guidelines doc. We will create links back to the guidelines from the checkpoint map. [Done]
Issue raised by: AC Member
Issue category: Change in requirement
Resolved: 27 April 1999
4.2. Lower the priority of expanding abbreviations and acronyms to priority 3. ["4.2 Specify the expansion of abbreviations and acronyms. [Priority 2 for the first occurrence of the acronym or abbreviation in a given document, Priority 3 thereafter.]"] To expand abbreviations and acronyms is good writing style. This checkpoint is not an accessibility issue. We know of no user agents that support the ACRONYM or ABBR tag. It should be priority 3.
We don't have consensus to change the priority. The group agrees that they don't want to sacrifice the document over this issue. Phil Jenkins is checking with cognitive disability experts to see if the priority should be maintained for cognitive disability issues. If it does not, then the group feels that a P3 is acceptable.
Changed to P3 based on comments from Phil.
Issue raised by: AC Member
Issue category: Change in requirement
Resolved: 27 April 1999
An AC Member asked that we remove the priority 2 requirement for redundant text links for client-side image maps which is found in Checkpoint 1.2 They felt that client side image maps are handled by text browsers and assistive technologies today. They suggested that 1.2 should say to provide redundant links for server-side maps, when server-side maps are required.
They also suggested we refer to Checkpoint 9.1 in checkpoint 1.2.
In examining this item, it was found that there are user agents for all platforms that will process client side image maps. Thus the second list of links is not necessary to provide access. In fact, it can be confusing on these browsers since it lists all of the links twice. However, it is still a usability problem for those who prefer browsers that do not expose client side links very well.
The proposal is therefore to set the priority to 3 for client side image maps because of the interference problem and the fact that access is available through multiple browsers (Lynx, Opera, Pwwebspeak, HomePage Reader, etc.) The priority would remain 1 for server side image maps.
1.2 Provide redundant text links for each active region of an image map. [Priority 1 - if server-side image maps are used], [Priority 3 - if client-side image maps are used.] Redundant text links for client-side image maps are only required until user agents render text equivalents for the map links.
The priority of client-side image maps should have had a "until user agents" clause from the beginning.
Split into 2 separate checkpoints -
Use the proposed resolution (make client-side a P3).
Issue raised by: AC Member
Issue category: Editorial/Clarification
Resolved: 27 April 1999
One of the commenters felt that many of the messages in the public archive address important issues (in particular, Eric Hanson's revision to checkpoint 1.3)
They also felt that animation should be included in many places in the document to accompany "movie" e.g. in Guideline 1, checkpoint 1.3. They thought perhaps, "video and animation" would be better terms. Reason for the suggestion, is that they are referred to as video and animation in multimedia literature.
Checkpoint 1.3 has been revised to address the issues raised. Also some other changes have been made to reflect other comments on the list (see change log for details). Note that there are limits to what we can do to change the guidelines however, once they have gone to proposed recommendation.
SPECIFIC WORDING: RE Checkpoint 1.3
For your analysis, three versions of the checkpoint are shown here. First, the checkpoint as it was in the proposed recommendation. Second the checkpoint after the last teleconference call. Third, a new version to incorporate the "animation" issue. ORIGINAL CHECKPOINT 1.3
1.3 For each movie, provide an auditory description of the video track and synchronize it with the audio track. [Priority 1] REVISED CHECKPOINT 1.3
1.3 Until most video player technologies can generate an audio description of the video track from a text equivalent (see checkpoint 1.1), provide an auditory description of the video track (synchronized with the audio track per Checkpoint 1.4)
1.3 Until most user agents (including media players) can use speech synthesis to generate an auditory description of the visual track from its text equivalent, provide an auditory description of the visual track (synchronized with the audio track).
This does not apply to visual presentations that are silent, unless the presentation requires a time based user interaction. [Priority 1]
NOTE": (See checkpoint 1.1 regarding text equivalents to visual tracks)
Until user agents can automatically read visual description text aloud, provide an auditory description of the visual track (synchronized with the audio track).
Provide a description of the video information and synchronize it with the audio information.
[Rationale: there is no need for an audio description of a silent animation unless it is tied to time based interaction with the page (e.g. they need to do something when a particular visual event occurs) in which case it is important to know when something is happening visually. ]
1.3 Until most user agents can automatically read aloud the text equivalent of the visual track, provide an auditory description of the important information in the visual track of multimedia presentations. [Priority 1] (Note: Per 1.4 this must be synchronized with the audio track) (See 1.1 regarding text equivalents for visual information)
**[Note: If there is no important visual information (e.g. a talking head) then a visual description is not required.] --- goes into techniques doc
Rationale: animation is covered if part of a presentation. This will be made clear in the techniques doc. Other animations that are part of programmatic interactions are covered elsewhere.
Minority position: Eric Phill: Full compiled text would provide Basic level access to the information. (p1) Providing Auditory description would provide better access or p2 level access.
Issue raised by: AC Member
Issue category: Editorial/Clarification
Resolved: 27 April 1999
Regarding Checkpoints 1.3 and 1.4 requiring synchronized alternative multi-media:
"1.3 For each movie, provide an auditory description of the video track and synchronize it with the audio track" "1.4 For any time-based presentation (e.g., a movie, animation, or multimedia presentation), synchronize equivalent alternatives (e.g., captions or video descriptions) with the presentation.
An AC Member agreed that text transcripts and text or audio descriptions should be a priority item. They did not feel however that important video information available as a text description is made more accessible by being synchronized with the video. They also did not feel that text transcripts of audio tracks of video information is made more accessible by being synchronized with video. They felt that it would be a huge burden to re-produce existing multimedia content in the varied synchronized formats and platforms. They felt that the guidelines need to be clearer in describing the formats that it requires. They felt that this was similar to internationalization issues of translating audio and video information. They felt that synchronizing the alternative content should be priority 3 and only applicable to new content produced.
The working group did not feel that having captions (or text transcripts of the audio tracks), available as a non-synchronized text files would allow people who were deaf to be able to watch a movie successfully. Nor did the group feel that a script of a movie (a text description of the audio combined with a description of the key visual events) was an equivalent to watching the movie for a person who could see. Similarly with video descriptions. It was not felt that these could be dropped in priority.
With regard to limiting this guideline to existing material: It was noted that the guidelines describe what makes web content accessible, and does not describe how these guidelines should be applied. It would be up to others to decide, for example, that certain guidelines or checkpoints should only be expected of new material. That is not a question of accessibility but of undue burden or some similar measure.
Finally, it was noted that tools are now becoming available that could take at script and automatically synchronize it with a movie. It will also be possible soon to have the video description part automatically voiced and synchronized. People generating videos could send the av material and a script (of the audio and key visual components of the AV material) over the internet to a robot that would voice and synchronize both the text and voiced material with the original AV material.
SPECIFIC WORDING: No changes proposed.
A working group member raised a related issue ( Eric Hansen - 6 Apr 1999 and that issue was resolved on 13 April 1999.
The possibility of synchronizing text equivalents for video was not acknowledged in checkpoint 1.3 [For each movie, provide an auditory description of the video track and synchronize it with the audio track.]
This idea is in checkpoint 1.4 [For any time-based presentation (e.g., a movie, animation, or multimedia presentation), synchronize equivalent alternatives (e.g., captions or video descriptions) with the presentation.] However, since it seems completely redundant with a portion of 1.4 have we left out an idea or has 1.3 been misrepresented? The editors will compare an older version with the latest and if nothing has been left out, delete this checkpoint. Otherwise, bring a new proposal for the wording of 1.3 to the group on Thursday.
ADD THE WORD MULTIMEDIA TO ITEM 1.4 AND DROP MULTIMEDIA PRESENTATION FROM EXAMPLE
Minority position: Eric Phill: Full compiled text would provide Basic level access to the information. (p1) Providing Auditory description would provide better access or p2 level access.
Put additional information on accessible formats in the Techniques document
Issue raised by: The Editors
Issue category: Editorial/Clarification
Resolved: 27 April 1999
The definitions of the equivalents need clarification.
A text transcript is a text equivalent of audio information that includes spoken words and non-spoken sounds such as sound effects. A caption is a text transcript for the audio track of a video presentation that is synchronized with the video and audio tracks. Captions are generally rendered visually by being superimposed over the video, which benefits people who are deaf and hard-of-hearing, and anyone who cannot hear the audio (e.g., when in a crowded room). A collated text transcript combines (collates) captions with text descriptions of video information (descriptions of the actions, body language, graphics, and scene changes of the video track). These text equivalents make presentations accessible to people who are deaf-blind and to people who cannot play movies, animations, etc. It also makes the information available to search engines.
One example of a non-text equivalent is an auditory description of the key visual elements of a presentation. The description is either a prerecorded human voice or a synthesized voice (recorded or generated on the fly). The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.
Issue raised by: AC Member
Issue category: Editorial/Clarification
Resolved: 27 April 1999
This item referes to checkpoint 4.1 which reads "4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions) of non-text content" An AC Member felt that checkpoint 4.1 should have the same priority as checkpoint 4.3 which has a priority of 3. They were aware of no browser or assistive technologies that supported the LANG attribute today. They felt that marking a phrase with the LANG attribute will not "make a difference" until user agents support it - and should not therefore be required above a priority 3 level.
Leave checkpoint as is. Clarify the issues in the description under 4. Describe that the synthesizer can apply the proper pronunciations so that words are recognizable to people who know those languages, so that when it is read aloud they are able to understand the changes. Speech synthesizers can switch between language pronunciations if they are aware of the language. Visual indications of changes in language allow persons reading the page visually to clue-in to the language change. Marking the language changes allows speech synthesizers to change languages to avoid confusion. For some people, to read this type of text, they need to translate the language codes then print the document in braille. Sometimes this requires sighted assistance, therefore it is not accessible without language markup.
Jason White is writing up explanatory text to be used in the Techniques document.**
When content developers mark up natural language changes in a document, speech synthesizers and braille devices can automatically switch to the new language, making the document more accessible to multilingual users. Content developers should identify the predominant natural language of a document's content (through markup or HTTP headers). Content developers should also provide expansions of abbreviations and acronyms.
In addition to helping assistive technologies, natural language markup allows search engines to find key words and identify documents in a desired language. Natural language markup also improves readability of the Web for all people, including those with learning disabilities, cognitive disabilities, or people who are deaf. Natural language markup may also enable machine translation of documents into other natural languages.
When abbreviations and natural language changes are not identified, they may be indecipherable when machine-spoken or brailled.
Issue raised by: AC Member
Issue category: Change in requirement
Resolved 23 April 1999
The wording for this item was originally 5.3 Avoid using tables for layout [Priority 2] This was immediately followed by another priority 2 item which read 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2]
This left an ambiguous guideline that sounded like you should avoid tables but that there were times when it was ok. Though exactly when this was was not clear.
To address this and the suggestions of the two AC Members, we propose to combine the two AC Members' suggestions.
This keeps the priority the same and clarifies when and how it is ok to use tables for layout and what to do if they are not accessible when linearized. It also adds a link from this guideline to the issue of proper use of markup, which is covered elsewhere but is so essential to tables. Finally, a note was added to remind authors that tables should not be used for layout once it is possible to use style sheets reliably.
The wording of 5.3 requires a definition of "linearized table" in this document, which does not currently exist. Also, I would make the following editorial changes to 5.3: "Do not use tables for layout unless the content makes sense when linearized. If this is not possible, provide a linearized version of the table that does make sense." The definition of linearized would be "rendered cell-by-cell in document order" and the definition of "makes sense" would be "(a) may be read coherently with respect to previous cells in a linearized table (b) contains appropriate markup." Or something like that.
Issue raised by: Advisory Committee (AC) member
Issue category: Combine, susume or eliminate
Resolved 23 April 1999
There may be downlevel versions of screen readers which do not deal with tables today, however there are accessible solutions even on older platforms. We cannot demand that web authors make this expensive adaptation to facilitate environment that are accessible. All text browsers and at least one graphics browser (Opera) handle tables today.
10.3. Remove the requirement for alternative equivalent pages for pages that have column wrapped text. ["10.3 Until user agents or assistive technologies render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns."]
The Working Group felt that technologies has indeed progressed recently, and many felt that they "until user agents" clause had been met. Others felt that it was close but that some tools to make older Microsoft and Netscape browsers handle tables were not yet available.
It was thought that the Clause was met enough that it was no longer a priority 2 since it was no longer a severe usability problem. One could use any of the browsers that did handle tables with side by side text and be able to read the text. There are also tools that should be out relatively soon that will plug into existing IE and Netscape browsers to allow them to unwrap tables on request from the user.
This seems to be the only workable solution based on new evidence w/in spririt of the original document.
Issue raised by: Advisory Committee (AC) member
Issue category: Editorial/Clarification, Bug
Resolved27 April 1999
The AC Member felt that the document does identify design issues, but they did not think its current form lent it to ready use by web page designers or evaluators. Their suggestion is to use this material as a basis for a design guide that is intended specifically as a tool for page authors, site designers, evaluators, and others. The introduction and definitions were a particular problem.
They also felt that accessibility by persons with disabilities is a major focus of this document, but the document also addresses additional issues including language, literacy, access by specific technologies, and special work environments. They suggested that we make use of the user or environment situations being addressed by each design recommendation more explicit as part of the suggestion for the design guide above.
First, we will review the introduction and definitions to clear up some issues like the definition of natural language, adding interim to the glossary, and mentioning that although the document touches on internationalization and device independence, that the document does not provide a comprehensive coverage of these topics. We will also mention that the Education and Outreach group is working on design guides and other materials to be used to present and train people in the use of these guidelines.
SPECIFIC WORDING: Natural Language: An interpersonal communication language that was developed within the natural course of people communicating with each other. This includes spoken, written and signed languages.
Ian counterproposal to this definition: Spoken, written, or signed human languages such as French, Japanese, American Sign Language, and braille.
Interim checkpoints: Checkpoints that are valid and necessary AT THE TIME OF PUBLICATION to allow people to access the web, but which we do not expect will be needed in the future after web technologies have incorporated one or more features or capabilities. Checkpoints that are interim all begin with the word "Until".
Added text to NOTE of Guideline 10: 'These checkpoints are classified as "interim", meaning that the Web Content Guidelines Working Group considers them to be valid and necessary to Web accessibility as of the publication of this document. However, the Working Group does not expect these checkpoints to be necessary in the future, once Web technologies have incorporated anticipated features or capabilities.'
ALSO CHANGE WORDING AFTER GUIDELINE 10 TO LOOK MORE LIKE THIS. CONSIDER DROPPING DEFINITION FROM END OF PROPOSAL
ALSO -IN USER AGENT DEF MAKE LINK TO W3C STAND OUT. (L INK IT TO TEHCNIQUES) Until user agents ...
Edited to be: "In most of the checkpoints, content developers are asked to ensure the accessibility of their pages and sites. However, there are accessibility needs that would be more appropriately met by a user agent or assistive technology. Unfortunately, as of the publication of this document, not all user agents or assistive technologies provide the accessibility control users require (e.g., some user agents may not allow users to turn off blinking content, or some screen readers may not handle tables well). Checkpoints that contain the phrase "until user agents ..." require content developers to provide additional support for accessibility until most user agents readily available to their audience include the necessary accessibility features."
"Note.The W3C WAI Web site will provide information about user agent support for accessibility features. [@@ add URI]. Content developers are encouraged to consult this information regularly for pertinent updates."
Issue raised by: Advisory Committee (AC) member
Issue category: Editorial/Clarification
Resolved 27 April 1999
How comprehensive is the coverage of i18n, portability, etc. issues?
Clarify that doc contributes to but does not comprehensively address i18n, device-independence, etc., then give pointers for where there is more info available on these issues.
Changes to abstract: "This is a reference document for accessibility principles and design ideas. Some of the strategies discussed in this document address certain Web internationalization and mobile access concerns. However, this document focuses on accessibility and does not fully address the related concerns of other W3C Activities. Please consult the W3C Mobile Access Activity home page and the W3C Internationalization Activity home page for more information."
Issue raised by: Advisory Committee (AC) member
Issue category: Editorial/Clarification
Resolved 27 April 1999
An AC Member thought that there was a topic missing in the guidelines. They felt that for applets it would also be nice to see a statement something like:
"Only use technology that provides an Accessibility API to build applets from. This way assistive technologies are able to access the information contained in them."
They felt that this way accessibility sensitized designers would have some guidance on what to look for in the technology the applet is to be based on and a user won't be forced to use some alternative to the applet when running in a browser that is able to display an applet.
They noted that this did place a requirement on the user to have an assistive technology that is compatible with the Accessibility API but that that was something beyond the scope of these guidelines.
This is covered in Guideline 8 which states
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]
Using an Accessibility API is discussed in the Techniques document as a strategy for doing this.
Therefore, no Change proposed to Guidelines doc itself.
Definition of UA - where does this go??
User Agents includes graphical desk-top browsers, voice browsers, text browsers, multi-media players, and the dependent assistive technologies that are used in conjunction with those to access information on the Web.
Ian: This is already in the glossary: "Software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some assistive technologies such as screen readers and screen magnifiers."