- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 22 Nov 1999 18:31:03 -0500
- To: ehansen@ets.org
- CC: w3c-wai-ua@w3.org
ehansen@ets.org wrote:
>
> Following are issues in the 5 November 1999 (Last Call) version of the UAGL
> document, not necessarily in order of criticality.
>
> Some of the changes are marked in ALLCAPS for emphasis.
For my comments on the first part of this message, refer to [1].
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0348.html
> ----
> Issue #7. Break checkpoint 6.1 into two separate checkpoints - 6.1.A and
> 6.1.B.
>
> The first would deal with adherence to WAI specs (WCAG and ATAG) and the
> second would deal with non-WAI W3C specs. See below for details.
[waiting until below...]
> ----
> Issue #8. Checkpoint 6.1.A. should have "Relative Priority".
>
> I think that to fail to use relative priority would be too much of a
> broadbrush approach and places an unnecessary burden upon the developer.
> Furthermore, by breaking out the WAI specs into its own checkpoint, the use
> of relative priority is much more understandable and limited in scope. _If_
> we feel that a WCAG checkpoint priority should be higher or lower when
> implemented in UAAG, then we should just add a specific checkpoints to say
> so. That would not be an insult to the other guidelines to do so.
>
> It is tempting to modify the phrasing to say "Implement the _applicable_
> accessibility featuresþ."but that meaning may be implicit.
> To add the word
> _applicable_ would, I think, require adding the phrase "applicable
> accessibility features" to the glossary.
What would it mean?
> Old: N/A
>
> New: "6.1.A. Implement the accessibility features of the specifications of
> Web Accessibility Initiative (WAI) of the W3C (Web Content Accessibility
> Guidelines [WCAG], Authoring Tool Accessibility Guidelines [ATAG])"
> [Relative Priority]"
Actually, there's no dependency in this direction on ATAG, only on WCAG.
> "Note 1. "Relative priority" means, for example, that a Priority 1 to a
> WCAG accessibility feature is Priority 1 for this document, that a Priority
> 2 WCAG accessibility feature is Priority 2, and that a Priority 3 WCAG
> accessibility feature is Priority 3. Any exception to relative priority
> will be specifically noted in this document. " {I don't think that there
> are currently any major exceptions.}
> ----
> Issue #9. Checkpoint 6.1.B should be modified to refer to "non-WAI W3C
> specifications"
>
> It should keep the same priority level (Priority 1). The words "e.g.,"
> shows that this is not a complete list. Retain the Priority 1 rating.
>
> Old: "6.1. Implement the accessibility features of supported specifications
> (markup language, style sheet languages, meta data languages, graphics
> formats)." [Priority 1]
>
> New: "6.1.B. Implement the accessibility features of supported non-WAI W3C
> specifications (e.g., markup language, style sheet languages, meta data
> languages, graphics formats)." [Priority 1]
ATAG has already dealt with this issue. From [2]:
7.1 Use all applicable operating system and accessibility standards
and conventions (Priority 1 for standards and conventions
that are essential to accessibility, Priority 2 for those
that are important to accessibility, Priority 3 for those
that are beneficial to accessibility).
[2]
http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026/#check-use-system-convention
> ----
>
> Issue #10. Checkpoint 6.2 should refer to refer to "non-WAI W3C"
> specifications.
>
> This change is made to account for the fact that WAI specs such as WGAG and
> ATAG are already addressed in checkpoint 6.1.A. I suppose that one could
> possibly retain the old wording, but then it would seem to contradict
> checkpoint 6.1.A. Retain the Priority 2 rating.
6.2 does not refer to accessibility standards, but all W3C
Recommendations.
6.1.A addresses accessibility featurse. 6.2 addresses general
conformance
(e.g., valid HTML markup).
> Old: "6.2. Conform to W3C specifications when they are appropriate for a
> task. [Priority 2]"
>
> New 1: "6.2. Conform to non-WAI W3C specifications when they are
> appropriate for a task. [Priority 2]"
>
> New 2 (alternative): "6.2. Conform to W3C specifications when they are
> appropriate for a task. [Priority 2]"
> "Note. Conformance to all applicable WAI specifications (e.g., WCAG and
> ATAG {spell out} is already required per checkpoint 6.1.A."
> ----
> Issue #11. Change "closed captions" to "captions" throughout the document.
Hmm, this was changed explicitly to "closed captions" because people
found "captions" alone confusion (e.g., they felt they referred
also to table captions, image captions, etc.).
> This change will bring the document into line with the WCAG and ATAG
> documents. The term "closed captions" seems far too narrow and is likely to
> confuse many people.
> ----
> Issue #12. Fix the expanded guideline statement for guideline 2.
>
> Guideline 2 has several problems.
>
> a. The term "descriptions of images" may seem to refer to "long
> descriptions" instead of alt-text.
> b. The term "closed captions for video or audio" is misleading and
> erroneous. First, the term "closed" should not be used (see elsewhere in
> this document). Second, the terms "video or audio" are extremely confusing
> because a caption is a text equivalent of an auditory track that is
> synchronized with the visual (and auditory track) of a multimedia
> presentation, but reference to "video or audio" jumbles everything up.
>
> I think that the phrase "e.g., text equivalents and prerecorded auditory
> descriptions (if applicable)" covers everything that is required by WCAG.
> Someone please correct me if I am wrong on this.
>
> Old:
> "Ensure that users have access to all content, notably author-supplied
> alternative equivalents for content (descriptions of images, closed
> captions for video or audio, etc.)"
>
> New:
> "Ensure that users have access to all content, notably author-supplied
> alternative equivalents for content, e.g., text equivalents and prerecorded
> auditory descriptions."
Yes.
> ----
> Issue #13. Delete reference to "braille" in the definition of natural
> language and in the main body.
>
> Is braille accepted as a natural language? If so, then I am surprised. You
> could, I think, express many different natural language (English, French,
> etc.) in braille. How many "lang" attributes can apply to the same text
> (two might be "English" and "braille")? I would recommend checking this
> definition with a linguist. Regardless of what linguists say, was this the
> intent of the "lang" attribute? I am sorry if I missed this in WCAG 1.0
> because the problem is also there.
>
> Old definition of "Natural Language":
>
> "Spoken, written, or signed human languages such as French, Japanese,
> American Sign Language, and braille. The natural language of content may be
> indicated in markup (e.g., by the "lang" attribute in HTML ([HTML40],
> section 8.1) or by HTTP headers."
>
> New definition of "Natural Language":
>
> "Spoken, written, or signed human languages such as French, Japanese, and
> American Sign Language. The natural language of content may be indicated in
> markup (e.g., by the "lang" attribute in HTML ([HTML40], section 8.1) or by
> HTTP headers."
I'll let the Braille experts illuminate.
> ----
> Issue #14. Fix definition of "assistive technology".
>
> Following is my attempt to clarify the definition. Note that there are
> several wording changes in the text.
>
> Old:
>
> "Assistive Technology"
> "Software or hardware that has been specifically designed to assist people
> with disabilities in carrying out daily activities. Assistive technology
> includes wheelchairs, reading machines, devices for grasping, alternative
> computer keyboards or pointing devices, etc. In the area of Web
> Accessibility, common software-based assistive technologies include
> assistive technologies, which rely on other user agents for input and/or
> output. These include: "
> "(bullet) screen magnifiers, which are used by people with visual
> impairment to enlarge and change colors on the screen to improve
> readability of text and images."
> "(bullet) screen readers, which are used by people who are blind or with
> reading disabilities to read textual information through speech or braille
> displays."
> "(bullet) alternative keyboards, which are used by people with movement
> impairments to simulate the keyboard."
> "(bullet) alternative pointing devices, which are used by people with
> movement impairments to simulate mouse pointing and button activations."
>
> New:
>
> "Assistive Technology"
> "In the context of this document, an assistive technology is a user agent
> that relies on one or more other user agents to help people with
> disabilities interact with a computer. For example, screen reader software
> is an assistive technology because it relies on Web browsers or other
> application software to assist people who have disabilities (especially
> visual and learning disabilities) in interacting with the computer. (More
> generally, an assistive technology consists of software or hardware that
> has been specifically designed to assist people with disabilities in
> carrying out daily activities, e.g., wheelchairs, reading machines, devices
> for grasping, alternative computer keyboards or pointing devices, etc.)
> Examples of assistive technologies that are important in the context of
> this document include the following."
> "(bullet) screen magnifiers, which are used by people with visual
> disabilities to enlarge and change colors on the screen to improve the
> visual readability of text and images."
> "(bullet) screen readers, which are used by people who are blind or have
> reading disabilities to read textual information through synthesized speech
> or braille displays."
> "(bullet) alternative keyboards, which are used by people with certain
> physical disabilities to simulate the keyboard."
> "(bullet) alternative pointing devices, which are used by people with
> certain physical disabilities to simulate mouse pointing and button
> activations."
Seems fine.
> ----
> Issue #15. Fix 1st paragraph of rationale for guideline 2.
>
> Old:
>
> "Users may not be able to perceive primary content due to a disability or a
> technological limitation or configuration (e.g., browser configured not to
> display images). Markup languages may provide a number of mechanisms for
> specifying alternative representations of content: through attribute values,
> element content, or as separate resources. User agents must also take into
> account markup related to natural language rendering, using appropriate
> fonts, text directionality, and synthesized speech elements."
>
> New:
>
> "User agents must be able to render content in a range of modes {or
I'm not sure about "must be able to render". That sounds like
a requirement. How about "UAs render content in a range of modes
...to meet the functional requirements of their users."
> modalities} -- auditory (synthesized and prerecorded), tactile (braille),
> visual, or in mixed mode -- that are required by individuals with
> disabilities. This high level of accessibility also requires that Web
> content developers provide alternative equivalents. (Refer to the Web
> Content Accessibility Guidelines [WAI-WEBCONTENT] for greater detail.)"
>
> Notes regarding changes:
>
> The meaning of the following sentence in paragraph 1 of guideline 2 is
> unclear: "User agents must also take into account markup related to natural
> language rendering, using appropriate fonts, text directionality, and
> synthesized speech elements." The phrases "take into account markup related
> to natural language renderingþ.and synthesized speech elements" are
> especially confusing. It is not clear what markup is NOT related to natural
> language rendering.
We mean "lang", "dir", BDO, xml:lang, etc. Perhaps we should
refer to "processing markup" (a term borrowed from Nir Dagan) that
indicates changes in natural language of content.
> Furthermore, virtually all text elements -- whether
> "primary" or alternative content -- are related to synthesized speech. It
> is not clear what a "synthesized speech element" is.
I agree.
> Note that if this recommended change is accepted, a later instance of
> "natural language" in UAAG will be the first occurrence and should have a
> hyperlink to the glossary.
Ok.
We need to review your proposed changes in the WG. Thank you
for taking the time to do a thorough review. More comments
on other threads....
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Monday, 22 November 1999 18:31:26 UTC