W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > March 2008

Fwd from Roger Hudson: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Mon, 24 Mar 2008 07:19:59 -0700
Message-ID: <824e742c0803240719k7991c85bv6d9400fac6c1286f@mail.gmail.com>
To: public-comments-WCAG20@w3.org

---------- Forwarded message ----------
From: Roger Hudson <rhudson@usability.com.au>
Date: Sun, Mar 23, 2008 at 8:12 PM
Subject: RE: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007
To: Loretta Guarino Reid <lorettaguarino@google.com>


Hi Loretta and Members of the Working Group,

 Thanks for sending me the responses to my comments regarding the
December 07 Draft of WCAG 2.0.

 As a general comment, I don't feel that the responses really address
many of the issues I raised. However, this was not unexpected given
the driving desire to get WCAG 2.0 out as soon as possible. I am not
sure whether the apparent failure to comprehend some of my concerns is
the result of my inability to express myself clearly, or unwillingness
on the part of the WG to understand them.

 While I appreciate the Working Group's desire for clarity and
testability, I also think that it is important to have guidelines that
advance the cause of accessibility and guidelines that are practical
to implement. I am concerned that some of WCAG 2.0 will be dismissed
by large sections of the web industry as basically not reflecting
their real world needs  see my comments relating to social networking
sites and the broadcast media.

 Following, are comments on some of the responses by the Working Group
to my comments on the December 07 Draft.

 Regards, best wishes and thanks for your work,


 Roger
 Roger Hudson
 Web Usability
 Ph: 02 9568 1535
 Mb: 0405 320 014
 Email: rhudson@usability.com.au
 Web: www.usability.com.au

 -----Original Message-----
 From: Loretta Guarino Reid [mailto:lorettaguarino@google.com]

Sent: Tuesday, 11 March 2008 11:21 AM
 To: Roger Hudson


Cc: public-comments-WCAG20@w3.org
 Subject: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

 Dear Roger Hudson,

 Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
 of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
 http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
 has reviewed all comments received on the December draft. Before we
 proceed to implementation, we would like to know whether we have
 understood your comments correctly and whether you are satisfied with
 our resolutions.

 Please review our resolutions for the following comments, and reply to
 us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
 you accept them or to discuss additional concerns you have with our
 response. Note that this list is publicly archived.

 Please see below for the text of comments that you submitted and our
 resolutions to your comments. Each comment includes a link to the
 archived copy of your original comment on
 http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
 also include links to the relevant changes in the WCAG 2.0 Editor's
 Draft of 10 March 2008 at
 http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

 Note that if you still strongly disagree with our resolution on an issue,
 you have the opportunity to file a formal objection (according to
 3.3.2 of the W3C Process, at
 http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
 to public-comments-wcag20@w3.org. Formal objections will be reviewed
 during the candidate recommendation transition meeting with the W3C
 Director, unless we can come to agreement with you on a resolution in
 advance of the meeting.

 Thank you for your time reviewing and sending comments. Though we
 cannot always do exactly what each commenter requests, all of the
 comments are valuable to the development of WCAG 2.0.


 Regards,

 Loretta Guarino Reid, WCAG WG Co-Chair
 Gregg Vanderheiden, WCAG WG Co-Chair
 Michael Cooper, WCAG WG Staff Contact

 On behalf of the WCAG Working Group

 ----------------------------------------------------------
 Comment 1: doing a little more for people with cognitive limitations
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Dec/0051.html
 (Issue ID: 2373)
 Status: VERIFIED / PARTIAL/OTHER
 ----------------------------
 Original Comment:
 ----------------------------

 Thanks for sending me the WG response to my response.

 I am sorry but I just don't understand how you are suggesting 1.1.1 offers
 any support for people with cognitive or learning difficulties. Guideline
 1.1 and 1.1.1, from my reading of the latest last call draft, seem to
 explicitly relate to the provision of text alternatives for non-text
 content. What I was specifically concerned about were people who had a
 problem reading or comprehending complex pieces of text, not people who need
 text alternatives for non-text content for I feel they are adequately
 catered for in WCAG 1 and 2.

 Do I take from this comment, "we do not have any requirements on the quality
 of the alt-text because that would create the same kind of testability
 problem", that the Working Group is not going to be concerned about the
 quality of the actual text alternative for non text content? If so, why
 include the phrase "presents equivalent information"?



Roger

 Roger Hudson
 Web Usability
 Ph: 02 9568 1535
 Mb: 0405 320 014
 Email: rhudson@usability.com.au
 Web: www.usability.com.au
 -----Original Message-----
 From: Loretta Guarino Reid [mailto:lorettaguarino@google.com]
 Sent: Wednesday, 12 December 2007 10:44 AM
 To: Roger Hudson

 Cc: public-comments-wcag20@w3.org
 Subject: Re: WCAG 2 response to WG response

 Yes the alt-text is a good comparison.  And we do not have any
 requirements on the quality of the alt-text because that would create
 the same kind of testability problem.

 The only failure is the use of the same placeholder term on all
 graphics (since that is easy to reliably detect/test for).

 Please note that there are many provisions at  Level A and Level AA
 that provide access for people with cognitive disabilities such as
 1.1.1 that allows content to be read aloud or translated into symbols
 etc.   In fact a majority of the provisions relate to issues that have
 been identified for one or another cognitive language or learning
 disability.   We know that there are many other issues that we were
 not able to address.  We have initiated an effort in conjunction with
 the Cognitive RERC on developing an application note on access to Web
 Pages by people with congnitive, language and learning disabilities
 that is more general, qualitative, and not bound by testability so
 that all guidance can be treated equally without levels or constraint
 due to the nature of the advice.

 Regards,

 Loretta Guarino Reid, WCAG WG Co-Chair
 Gregg Vanderheiden, WCAG WG Co-Chair
 Michael Cooper, WCAG WG Staff Contact

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 SC 1.1.1 ensures that all text is machine readable. That allows the
 text to be translated into other forms to meet user needs. For people
 with cognitive, language and learning disabilities it allows the page
 to be read aloud, translated into a user's symbol system, or
 translated into a simpler form. In fact we were talking to language
 translation experts recently and they felt that this was a real
 possibility using current and emerging language translation
 technologies.

 Regarding the quality of alt text, we do not require that it be of
 high quality, but we do require that it be equivalent and we do
 provide clear examples of things that are not equivalent.

 ----------------------------------------------------------
 Comment 2: Cognitive Support
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0013.html
 (Issue ID: 2389)
 Status: VERIFIED / PARTIAL/OTHER
 ----------------------------
 Original Comment:
 ----------------------------

 The previous two drafts generated 1,500 comments which according to
 the Working Group, "comprises a significant community contribution to
 the guidelines". Much of the response by the Working Group to these
 comments was in the form of additional clarifications and techniques
 in two non-normative documents that do not have the status of WCAG
 2.0.

 WCAG 1.0 adopted a general position of offering guidance in the area
 of accessibility; whereas during the development of WCAG 2.0, it
 appears that a prime aim has been to prepare a document that is more
 akin to a "standard". Perhaps, this is best illustrated by the Working
 Group's determination that the value of a Success Criteria be
 determined by its testability, and in particular machine testability.

 Given this apparent move from offering guidance to providing a
 (machine) testable standard, it would seem likely that the normative
 components of WCAG 2.0 will be the main area of concern when
 determining legal liability or responsibility for ensuring web
 accessibility. It should be noted, that in regard to the definition of
 "normative" the WCAG 2.0 Glossary states, "Content identified as
 "informative" or "non-normative" is never required for conformance".

 I am concerned that many issues relating directly to people with
 cognitive, learning or language difficulties, which were raised in
 response to the previous two drafts of WCAG 2.0, are still not
 addressed in the core WCAG 2.0 document. In fact, I believe it could
 be argued that from a legal perspective WCAG 2.0 offers less rather
 than more protection or support than WCAG 1.0 for what is arguable the
 largest community of disabled people in many countries.

 Proposed Change:

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 We do not believe WCAG 2 offers less *protection* for people with
 cognitive disabilities. While some provisions that might benefit some
 users are not included, WCAG 2 does not prohibit conforming Web sites
 from following such guidance, nor does it prohibit policies from
 adding additional guidance (where testability is not a concern). The
 additional resources provided are intended to support this.

 While it is true that WCAG 2.0 has an emphasis on testable criterion,
 it is not true that there is any bias toward machine testing except
 for a couple provisions like 'flash' where things happen too quickly
 to be evaluated well by humans. In fact almost all of the provisions
 require humans in testing.

 That said, it is true that the cognitive, language and learning areas
 are some of the most difficult to identify testable techniques for
 direct access. In WCAG 1.0, there were provisions like "Use the
 clearest and simplest language appropriate for a site's content," but
 in practice we found that the provision was largely ignored. The
 attempt in WCAG 2.0 was to create provisions that could be tested and
 that would be included when sites were tested.

 We have tried to include all of the qualitative guidance that we have
 received in the advisory techniques.  We have also re-written the
 introduction to emphasize the importance of going beyond the testable
 SC and implementing as many of the sufficient and advisory techniques
 as possible.

 In addition, the WCAG WG has initiated an effort to develop an
 "application note" under the framework of WCAG 2.0 on access to Web
 Pages by people with cognitive, language and learning disabilities.
 The application note would include approaches that are more general,
 qualitative, and not bound by testability, so that all guidance can be
 treated equally without levels or constraint due to the nature of the
 advice. This effort will include the Cognitive Rehabilitation
 Engineering Research Center which focuses on cognitive disabilities,
 and we welcome additional participation.

 The WAI continues to be interested and committed to developing
 guidance to address Web accessibility needs in the broad area of
 cognitive disabilities, and will continue to explore this area through
 our other WAI 2.0 guidelines, research discussions, and in potential
 future guidelines development.

 It is hopeful to note that assistive technologies for people with
 cognitive disabilities, including free open source technologies, are
 on the horizon.  A large number of the provisions in WCAG 2.0 are
 designed to provide the information needed by these new and emerging
 technologies.

 The group feels that WCAG 2.0 has more enforceable provisions that
 deal with cognitive language and learning disabilities than WCAG 1.0.
 Still, the guidelines point out clearly that WCAG 2.0 is not enough
 for these groups and that more work is needed and that Web authors
 need to look beyond WCAG for all disabilities but particularly for
 users with cognitive language and learning disabilities.


 ---------------------------------------------------
 Comment on WG Response
 ---------------------------------------------------
 I agree with the WG that many people ignored the WCAG 1.0, provision
"Use the clearest and simplest language appropriate for a site's
content. (14.1)". But I for one, did take it seriously. At the risk of
repeating myself, I would like to briefly outline a case just last
year. A large government department (who recognise that over 30% of
their clients are functionally illiterate), recently asked me to
assess a site designed to provide information to their clients. The
information was all text based, often using quite complex language.
When I suggested they include a short Flash animation to communicate
the same basic information to those who might have a problem reading
all this text they responded, we have to make our sites Priority 1 and
Priority 2 compliant and this would be very difficult to do if we
include Flash. I then drew their attention to WCAG 1.0  CP 14.1 (P1)
and 14.3 (P3) and advised them to include the Flash so that their site
was both more accessible and more inline with the intentions of WCAG.
They agreed to do so, but I think this was only because I was able to
show them that there was a Priority 1 requirement to make something
understandable and if this was not possible provide some form of
alternative.

 What I want to know; where in the normative part of WCAG 2.0 is there
anything similar?

 With reference to this response: "The group feels that WCAG 2.0 has
more enforceable provisions that deal with cognitive language and
learning disabilities than WCAG 1.0." SC 3.1.5  Reading Level, which
is at AAA, does offer some support for people with reading
difficulties, but are there any other enforceable provisions that are
at A or AA level? I fully support the good intentions and long term
hopes of the WG but I wanted to see was a little more muscle in the
normative document.

 I am intrigued by the notion that it is acceptable to remove a
provision because in the view of the WG, "in practice we found that
the provision was largely ignored". I will return to this point later.




 ----------------------------------------------------------
 Comment 3: accessibility of social networking site content
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0014.html
 (Issue ID: 2390)
 Status: VERIFIED / PARTIAL/OTHER
 ----------------------------
 Original Comment:
 ----------------------------

 During the last few years, there has been an explosion in the use of
 social networking sites like Flickr, Youtube and Myspace and it is not
 clear how WCAG relates to all this new content on the web. Much of the
 content on these social networking sites does not comply with WCAG. It
 is probably unreasonable to expect all the users of these sites to be
 aware of what is required to make their contributions accessible and
 unrealistic to assume that they will have the desire to do so.

 When it comes to the accessibility of social networking sites, maybe
 we should look more at the processes that allow people to put material
 on the web, rather than the final content. That is, everyone should
 have the opportunity to participate, for example the process should
 allow a blind person as well as a person with cognitive limitations to
 set up a blog or a myspace page or put photos up onto Flickr, and then
 make this material available to as wider audience as they wish.

 The applications (tools) should encourage the users of these sites to
 include accessibility features. But if they don't, the application
 should degrade gracefully so that the resulting content does not cause
 problems for assistive technology users and wherever possible provides
 some basic text alternatives derived from the titles or descriptions
 provided by the person uploading the content.

 Proposed Change:
 The issue of the accessibility of user-generated content on social
 networking sites should be directly addressed in WCAG. In particular,
 there should be guidance about who is responsible for ensuring the
 content of these sites is accessible and how this could be best
 achieved.

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 WCAG describes the properties of a conforming web page, not the
 process used to generate the web page. Because there is a mix of
 authors on social networking web pages, with the users becoming
 authors of parts of their own pages, they are examples of Web pages
 which may only be able to make a statement of partial conformance.
 (http://www.w3.org/WAI/GL/WCAG20/#conformance-partial) The Web site
 authors make the standard portions of the Web pages conform to WCAG 2
 but they cannot make the full page conform without monitoring it and
 fixing any non-conforming content. Those pages would have to be
 excluded from a claim of conformance but could state that they would
 conform if all contributed content is excluded.

 Since such sites are often authoring tools, they should be encouraged
 to meet the Authoring Tool Accessibility Guidelines, as well.

 ------------------------------------------------------
 Comment on WG response
 ------------------------------------------------------
 There is a vast and rapidly increasing amount of content on social
networking sites and nearly all of it is inaccessible. With my
comment, all I was trying to suggest is that the new WGAG should
recognise this fact and make some suggestions about how to improve the
situation. Dismissing this as a "process" issue doesn't make it go
away. WCAG 1.0 failed to come to grips with non-W3C format material
and we know where that led, what will happen if the W3C fails to come
to grips with this recent phenomenon?

 I feel that in a practical sense, when it comes to the accessibility
of web content there is a qualitative and quantitative difference
between the content of a social networking site like Myspace, and a
site from for example a government department with information that
could be critically important to all web users, including those with
disabilities.

 To return to the Working Group belief that it is acceptable to remove
a provision that is "largely ignored", what happens with WCAG if, for
example the majority of new web content, totally ignores all the WCAG
provisions?




 ----------------------------------------------------------
 Comment 4: meaningful and logical sequence
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0015.html
 (Issue ID: 2391)
 Status: VERIFIED / NOT ACCEPTED
 ----------------------------
 Original Comment:
 ----------------------------

 The actual wording of this Criterion appears to relate only to the
 need for a "correct reading sequence" to be programmatically
 determined. No definition is provided for what is meant by "correct
 reading sequence" and the Understanding SC 1.3.2 document appears to
 be primarily concerned with ensuring assistive technologies do not
 distort the presentation of material in such a way as to confuse the
 users of these technologies.

 I feel that it is also important for material to be presented in a
 logical and clear way, particularly for people with cognitive and
 learning disabilities. Of course, I recognise it is not possible to
 determine if something is "logical" with a machine; however I believe
 it is very possible for human testers to reliably determine when the
 sequence of content or information is not meaningful or logical.

 SC 1.3.2 should be rewritten so that it is also able to provide some
 assistance to people with cognitive limitation, see following example;

 Proposed Change:
 1.3.2 Meaningful Sequence: When the sequence in which content is
 presented affects its meaning, the reading order of the material is
 logical and a correct reading sequence can be programmatically
 determined. (Level A)

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 A correct reading order will be one in which the words of a sentence
 are in order and the sentences of a paragraph are in order. That is,
 the order of the words in the sequence cannot be changed without
 affecting its meaning.

 The working group has considered the use of "logical" in various
 success criteria in the past, and has come to the conclusion that it
 is not testable. In this case, the current explanation of correct
 reading order captures the property that human testers would find
 agreement about.

 We recognize that there are additional requirements related to how
 information is organized that affects people with some cognitive and
 learning disabilities. However, we have not been able to develop
 success criterion for determining when the content has been organized
 in a way that addresses those requirements.

 ----------------------------------------------
 Comment on WG response
 ---------------------------------------------
 It would be useful to include your definition of correct reading
order in the Glossary, which is normative:
 "A correct reading order will be one in which the words of a sentence
are in order and the sentences of a paragraph are in order. That is,
the order of the words in the sequence cannot be changed without
affecting its meaning."



 ----------------------------------------------------------
 Comment 5: meaning of accessibility supported unclear
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0016.html
 (Issue ID: 2392)
 Status: VERIFIED / PARTIAL/OTHER
 ----------------------------
 Original Comment:
 ----------------------------

 The whole issue of "accessibility supported" evolved from the concept
 of "Baseline" which was widely misunderstood and/or incomprehensible
 by many people. Unfortunately I don't find "accessibility support"
 much clearer. The definitions and descriptions of "accessibility
 supported", which are provided in the WCAG 2.0 and "Understanding
 Accessibility Supported" documents, and the implications for web
 pages, I find difficult to understand.

 Does the issue of "accessibility supported technologies" only come
 into play if someone wishes to make a formal claim for conformance?
 Or, does it also relate a more general determination of whether or not
 a web page conforms to a particular Success Criterion? If so, who will
 be responsible for determining the supported technologies?

 When a regulator or court is asked to determine if a web site is
 inaccessible, is it the expectation of the Working Group that the
 guidelines for determining if a technology is accessibility supported
 will be taken into consideration?

 It seems to me that the information about "accessibility supported
 technologies" in the WCAG document body and Glossary raises a number
 of issues or questions including:

 1. The document talks about a technology being able to support
 accessibility but it does not appear to mention the implementation of
 that technology. For example, Flash, AJAX, PDF that are well made can
 be accessible, but poorly implemented are totally inaccessible. Is it
 sufficient to use an "accessibility supported technology" or should
 the use of that technology be accessible?

 2. The Working Group and W3C don't see the need to specify "which or
 how many assistive technologies must support a Web technology in order
 for it to be classified as accessibility supported". Point 2 in the
 Glossary says, "The web content technology must have
 accessibility-supported user agents that are available to users". Does
 this mean that a content technology can be considered accessible so
 long as a version of user-agent that supports that content technology
 is available in the market place regardless of the price of the
 user-agent or how many people use it?

 3. In my opinion, Point 2d in the Glossary is pretty worthless.
 Charging someone with a disability more for a user agent (assistive
 technology) than you would charge a non-disabled person is not really
 the point and many countries have discrimination or trade laws that
 would already cover this situation. Surely, the key issue is the
 additional cost of accessing a web service that someone who is
 dependant on an assistive technology needs to pay when compared to
 someone who can access the same service without requiring an assistive
 technology. Given that only one of the four conditions in Point 2
 needs to be true, Point 2d appears to be the ultimate escape clause
 under the guise of offering protection and needs to be rewritten.
 Obviously, assistive technology manufacturers shouldn't be asked to
 provide their products without charge. However, I believe it is
 equally obvious that making available a 1 million dollar tool that is
 priced the same for everyone, but is only essential for a person with
 a disability who wants to access a specific service, is not an
 equitable or fair solution.


 I fully recognise that my interpretation of the meaning and intent of
 "accessibility supported" maybe wrong, and if that is the case I
 apologise for my mistake. But if I am wrong, then it is likely others
 may experience problems understanding this.


 Proposed Change:
 The Working Group should consider re-writing the information relating
 to "accessibility supported" with the aim of providing greater
 clarity.

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 You raise a number of questions.  Lets look at them in turn.

 RE your numbered questions:
 1) It is necessary that conforming content both use techniques that
 satisfy the success criteria, and that those techniques are
 implemented using technologies  that are supported by user agents and
 assistive technology.

 One of the conformance requirements is that the success criteria must
 be met using accessibility supported technologies.  However if one
 uses accessibility supported technologies - but does not use them
 properly then the SC would not be met (and of course conformance could
 not be be claimed for levels that include that SC).  In the cases you
 specified, the content would fail the SC so just using an
 accessibility-supported technology but not using it properly would not
 be adequate to claim conformance.  Note that HTML done poorly would
 also fail the SC.



 2)  The working group recognizes that the need for information on which
 technologies are 'accessibility-supported' is important to use of the
 guidelines.

 Such data can only come from testing different versions of user
 agents and assistive technology and recording whether the features of
 the technology are supported. We expect that this information may
 need to be compiled from multiple sources. WAI will be working with
 others to establish an approach for collecting information on the
 accessibility support of various technologies by different user
 agents and assistive technologies.

 WCAG 2.0 is still in development. We expect that during Candidate
 Recommendation period we will have some initial information on
 accessibility supported technologies, to demonstrate how this
 approach will work once WCAG 2.0 becomes a W3C Recommendation.

 The Candidate Recommendation process itself requires that there be
 examples that demonstrate conformance. So there will certainly be some
 information about accessibility supported technologies in order to get
 out of the candidate recommendation stage for WCAG 2.0.

 3) The first three items in part 2 (of the definition) that you cite
 all involve the person with a disability using the same technology as
 everyone else.  So the problem of a person with a disability paying
 more would not arise.   The only reason that the language was required
 in part (d) was that (d) allowed for a special version of a plug in.
 For example, at one time the standard PDF plug in was not accessible.
 Instead, a special version that was accessible was provided.
 According to (d) that one had to be as easy to find and not cost any
 more than the standard one.  Today, the standard PDF plug in is
 accessible so it would fall under (b).   If you read (d) carefully it
 says that the tools that the person with a disability must use cannot
 cost more than the mainstream tools.  So other than people who must
 use AT (and must pay for the AT) there cannot be additional 'services'
 that are required that cost more than the services used by people
 without disabilities.

 Other questions you raised:

 Question:  "Does the issue of "accessibility supported technologies"
 only come into play if someone wishes to make a formal claim for
 conformance? Or, does it also relate a more general determination of
 whether or not a web page conforms to a particular Success Criterion?
 "
 Answer: It relates to conformance, regardless of whether a claim is
 made or not.

 Question:  "If so, who will be responsible for determining the
 supported technologies?"
 Answer:  The author is responsible.  They may rely on lists provided
 to them by others (the field, their company, a customer, etc.)

 Question: "When a regulator or court is asked to determine if a web
 site is inaccessible, is it the expectation of the Working Group that
 the guidelines for determining if a technology is accessibility
 supported will be taken into consideration?"
 Answer:  Yes.  If the regulation or court is using WCAG 2.0 as a
 reference they would usually use (and should use) all the normative
 aspects of WCAG 2.0.  What regulators or courts actually do, though,
 is up to them.
 --------------------------------------------------
 Comment on WG comment
 -------------------------------------------------
 I guess we are just going to have to wait and see how this pans out
during the Candidate phase.

 I am afraid that without clearer guidelines in regard to what can be
deemed to be accessibility supported, and if as you indicate, "The
author is responsible" for determining if a technology is
accessibility supported, this notion will make it harder for
governments to legislate/regulate for accessibility. Without clear
guidelines, I believe there is a real risk that entities will be able
to play the jurisdictional game in order to avoid their
responsibilities in the area of accessibility.



 ----------------------------------------------------------
 Comment 6: Media exemption to 1.1.1
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0017.html
 (Issue ID: 2393)
 Status: VERIFIED / PARTIAL/OTHER
 ----------------------------
 Original Comment:
 ----------------------------

 I don't fully understand the intention of the "media" exemption to the
 requirement to provide a text alternative for all non-text content
 under SC 1.1.1. I assume it is an attempt to accommodate the
 increasing presentation of audio and video material on the web by
 media not traditionally associated with the web; and, the need to
 balance the accessibility implications of this use with a desire to
 have guidelines that don't impose undue hardship on web proprietors or
 stifle the development of the web.

 The terminology used for the Media related exemption is potentially
 ambiguous in the context of the broadcast industry. In particular, it
 appears to address just two distinctly different programming formats,
 "live" and "prerecorded", without providing adequate definitions for
 either.

 The WCAG 2.0 Glossary defines the term "live audio-only" as "a
 time-based live presentation that contains only audio" and a very
 similar definition is provided for "live video-only". While these
 definitions might be adequate for a sports broadcast or the coverage
 of an unfolding news event, they do no appear to be sufficient for
 many of the situations faced by the broadcast media today.

 The current definitions of live audio-only and live video-only need to
 be expanded in order to meet the real-world needs of the media. The
 phrase 'time-based' is not very meaningful since within the broadcast
 industry all material could be said to be time-based.

 The proposed Media exemption does not recognise that sometimes a media
 broadcast (program) might be an amalgam of live and prerecorded
 material. For example, daily live radio programs often contain
 prerecorded segments: In some cases differences in time-zones or the
 schedule of the interviewee require an interview that is presented
 live to be prerecorded; or a live program may incorporate prerecorded
 documentary-style feature segments. With regard to television, it is
 not uncommon to have programs that are presented as live, but which in
 fact consist entirely of prerecorded segments with the only live
 component being the studio presenter who tops and tails them, and in
 some cases even this is prerecorded.

 Also, the broadcast of live-to-air (real-time) programs that contain
 absolutely no prerecorded material is becoming increasingly rare; even
 sports broadcasts often now contain prerecorded comments from the
 players. It should be noted, the Guidelines indicate use of
 "prerecorded" audio and video "files" is covered by SC1.1.1, but no
 definitions are provided for the words "prerecorded" and "files". Does
 a prerecorded interview with a player that is stored as an audio file
 require a text alternative within the context of the WCAG 2.0? Or,
 should it be treated as being part of a live audio or video
 presentation and so require only a descriptive label?

 The increasing convergence of media is resulting in more and more
 radio and television broadcast material now being presented over the
 web in a variety of ways. For example, ABC Radio National in Australia
 produces live and prerecorded programs and simultaneously "streams"
 all them over the internet at the time of broadcast. 95% of these
 programs are also available as "streamed media on demand", which means
 they can be listened to (but not downloaded) at a different time. In
 addition, over 50 of the daily or weekly programs are available for
 download as MP3 or Podcast files. These are primarily word based
 (non-music) information style programs. I understand the national
 broadcasters in Canada and the UK do something very similar.

 The presentation of steamed media on demand and podcasts on websites
 may further complicate the distinction between live and prerecorded
 content. This material, by its very nature, is not live in the sense
 that it is a recording of something that has happened at sometime in
 the past. In some cases however, it might be a recording of a
 live-to-air program and as such may be considered an alternative
 presentation of the initial program and so exempt from the need to
 provide a text alternative; this assumes the initial program is a
 live-only program within the meaning SC1.1.1.

 >From a practical point of view, it might be useful to consider making
 a distinction between 'scripted' and 'non-scripted' content since any
 requirement to provide a text alternative for a scripted program is
 likely to be less onerous. However, this should not mean that
 'non-scripted' material with historical value (e.g. an interview with
 someone concerning a significant world event) is exempt from the
 requirement to provide a text alternative when it is being presented
 on the web for posterity.

 Is the intention of the Media exemption to SC 1.1.1, and the
 associated definition, to exempt only live-to-air material from the
 need to provide a text alternative? And consequently, require all
 prerecorded material that is contained in a television or radio
 program to have a text alternative when it is presented on the web. If
 so, the considerable difficulties most broadcasters will experience in
 meeting such a demand is likely to lead to it being generally ignored.
 And, a general refusal by the broadcast industry to conform to a Level
 A Success Criterion could undermine the status of WCAG.

 Proposed Change:
 The Glossary should contain definitions for the terms "live" and
 "prerecorded" that relate to the current status of the broadcast
 industry and are likely to be meaningful to people working in the
 broadcast industry.

 The Working Group should consider providing greater flexibility in the
 Media exemption to SC 1.1.1, while still retaining the overall desire
 for text alternatives to be provided for television and radio
 broadcast material that is re-presented on the web.

 The Working Group might like to consider extending the Media exemption
 to allow programs that are presented in "real-time" (e.g. daily radio
 shows, sports broadcasts, current affairs tv) to contain a percentage
 of "prerecorded" material (e.g. 25%) without the need to provide a
 transcript for that material.

 The Working Group might like to consider incorporating a
 time-dimension into the Media exemption for SC 1.1.1. For example, a
 text alternative for non-text content should be provided within 14
 days. This would allow broadcasters sufficient time to prepare text
 alternatives for substantial programs and would enable them to
 continue to provide "streamed media on demand" for 14 days without the
 need to include a text alternative.

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 Answering your questions in turn:

 1)  No - the media exemption is not in response to any mainstream use
 of media. It is meant for media alternatives to what is already on the
 page where  the media alternatives are provided for accessibility
 reasons.  This is defined if you click the link for the phrase "media
 alternative for text" in the provision.   (note we changed
 "alternative for text" to "media alternative for text" in the
 provision)

 2) Regarding terminology - we have now defined "live" and
 "prerecorded".  These new definitions should address your 'sports' and
 'unfolding news event' question as well.

 3) Correct.  All broadcast streaming material would be time based.

 4) We have reworded the 1.2 success criteria to remove the ambiguity.
 If there is mixed live and prerecorded, each follows the guideline for
 its type of media.  Although not required, it would of course be
 preferred if the mixed media were to follow the more accessible
 "prerecorded" rules.

 5) With regard to 14 day exemptions and the like, those types of rules
 are outside of the scope of WCAG.  WCAG is like a measuring stick. It
 is used to measure the level of accessibility but not to state where
 different levels should be applied.

 ------------------------------------------------
 Comment on WG response
 ------------------------------------------------
 I apologise if I misunderstood the intention of the "Media, Test,
Sensory" exemption provided in the December 07 Draft.

 However, I would like the WG to address the issue of the increasing
use of the web to provide audio and video content that is a mix of
live and pre-recorded material. As with my response to Comment 3, we
just can't pretend it doesn't happen. Look at the website of any major
broadcaster and you will see many examples of what I described. Based
on your responses to my comments, I assume this must covered by
Guideline 1.2.

 While it is nice to see definitions of "live" and "pre-recorded",
they are very brief and I don't believe they address the fundamental
issues I raised. With the exception of streamed media, nearly all the
broadcast material that different broadcasters make available on the
web is in essence pre-recorded before it goes on the web, this is the
nature of the process. It is unrealistic to assume broadcasters are
going to make transcripts of all this material simultaneously
available.

 When I suggested the WG might look at providing some sort of time
frame with reference to the need to provide text alternative for
video/audio material, the Working Group responded, "Those types of
rules are outside of the scope of WCAG.  WCAG is like a measuring
stick. It is used to measure the level of accessibility but not to
state where different levels should be applied." I find it hard to
reconcile this response with the WG willingness to precisely define
the amount of screen that can flash at a "typical viewing distance"
when determining the general flash and red flash thresholds: - Is this
not indicating where different levels should be applied?

 To return to the Working Group belief that it is acceptable to remove
a provision that is "largely ignored", what happens with WCAG if, for
example many, or all, of the main media organisations in the world,
feel that complying with WCAG is just not a realistic options.

 As I said in my original comment, "a general refusal by the broadcast
industry to conform to a Level A Success Criterion could undermine the
status of WCAG."




 ----------------------------------------------------------
 Comment 7: Provide no keyboard trap information in context
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0018.html
 (Issue ID: 2394)
 Status: VERIFIED / NOT ACCEPTED
 ----------------------------
 Original Comment:
 ----------------------------

 In cases where moving focus away from a component with the keyboard is
 relatively complex, this criterion requires users to be advised of a
 method for doing this. However, neither the Success Criterion nor the
 How to Meet and Understanding documents appear to suggest where or how
 this advice should be provided. It would seem to be most appropriate
 to offer the advice within the context of the component and in my view
 providing the advice on a generic accessibility information page would
 not be adequate.

 Proposed Change:
 Success Criterion rewritten as follows:

 2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component
 of the page using a keyboard interface, then focus can be moved away
 from that component using only a keyboard interface, and, if moving
 focus away requires more than unmodified arrow or tab keys, a
 mechanism is provided in conjunction with the component to advise
 users how to move focus away. (Level A)

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 We have purposely not specified in the SC where the instructions would
 need to be provided. It may be on the page. Or, for an application,
 the instructions may appear at the front pages rather than being
 repeated on hundreds of pages that are essentially identical in
 operation, but gather different data.

 ----------------------------------------------------------
 Comment 8: Essential Exception
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0019.html
 (Issue ID: 2395)
 Status: VERIFIED / PARTIAL/OTHER
 ----------------------------
 Original Comment:
 ----------------------------

 When it comes to time limits the Criterion requires at least one of a
 number of conditions to be true. These include, "Essential Exception:
 the time limit cannot be extended without invalidating the activity."
 There appears to be no additional definition of what constitutes
 "essential" or advice on interpreting this condition.

 As it stands, it appears that it would be possible to declare that any
 event maybe deemed to be invalidated by extending the time-limit.

 Proposed Change:
 The Working Group consider removing "Essential Exception" since it
 would appear that all likely essential exceptions would already be
 covered by the "Real-time Exception" condition.

 If this is not possible, the Working Group should provide a precise
 indication (with example) of what constitutes an Essential Exception.

 Received on Tuesday, 22 January 2008 00:40

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 We have added a definition of essential that reads:

 essential
  if removed, would fundamentally change the information or
 functionality of the content, and information and functionality can
 not be achieved in another way that would conform


 ----------------------------------------------------------
 Comment 9: Changing SC for re-authentication after time limit expiration
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0020.html
 (Issue ID: 2396)
 Status: VERIFIED / NOT ACCEPTED
 ----------------------------
 Original Comment:
 ----------------------------

 Time limits can present problems for many people with disabilities and
 these problems can be greatly exacerbated when a session expires and
 data is lost. Currently this is a Level AAA Criterion.

 Although moving this up to Level AA has been rejected before by the
 Working Group, I don't believe the explanation offered in Point 2.2.6
 of the Issues and Changes Summary document is sufficient to justify
 keeping this Criterion at Level AAA.

 Proposed Change:
 Move SC 2.2.5 Re-authenticating up to Level AA.

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 Our apologies. In trying to keep the changes document short, we
 shortened some of our rationales. Here is the full rationale for not
 changing the level:

 The working group has discussed this issue at length. The criteria for having
 something at Level AA is that it must be something that can reasonably be
 applied to all Web content.

 But there are valid reasons, such as financial security or personal
 information where this cannot be done because it is against
 regulations to preserve any of this information once a session expires
 or is terminated.

 Also, this success criterion requires control of the server that may
 not be possible for some authors and technologies.

 It is also a new success criterion in WCAG 2.0 and there is little if
 any experience with the requirement and the solutions.

 For these reasons, the Working Group decided to put this requirement
 at Level AAA.

 ----------------------------------------------------------
 Comment 10: Change SC level for flashing content
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0021.html
 (Issue ID: 2397)
 Status: VERIFIED / NOT ACCEPTED
 ----------------------------
 Original Comment:
 ----------------------------

 Guideline 2.3.2, which relates to flashing content that is known to
 cause seizures, contains two Success Criteria. The first, which is at
 Level A, requires web pages to have no content that flashes more than
 three times in one second or the flash is below defined "general flash
 and red flash thresholds". The second criterion, which is at Level
 AAA, requires web pages not to contain anything that flashes more than
 three times a second.

 When it comes to determining the "general flash and red flash
 thresholds" the amount of screen that the flashing content can occupy
 is precisely defined in one sense, however there appears to be an
 assumption that typical viewing involves a display area of 1028 x 768
 pixels and a viewing distance of 56-66 cm. The Understanding SC 2.3.1
 document does not appear to provide any advice or examples for meeting
 the needs of users with impaired vision who do not conform to these
 typical viewing conditions.

 For screen magnifier users it is not uncommon for the entire display
 area to occupy less than 25% of a typical 1028 x 768 screen. Also, the
 field of view for people with tunnel vision or other vision
 impairments is often very different to the "typical". For these
 people, the combined area of flashing content that is deemed
 acceptable under the "general flash and red flash thresholds" may well
 be excessive.

 Given that Guideline 2.3 recognises certain flashing content is a
 known to cause seizures, I believe WCAG 2.0 should provide greater
 support for people with impaired vision who might also be at risk of
 seizures, and give greater guidance to developers in how to minimise
 this risk.

 Proposed Change:
 Move SC 2.3.2 Three Flashes up to Level AA.

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 Success Criterion 2.3.2 bans many things including video of natural
 phenomenon (e.g. lightning strikes) common video occurrences  (sun
 shining through a row of trees) and some movie effects (any machine
 gun) even if they are small or muted.   As such, it is quite
 restrictive of content.  The group did not feel that it should be at
 level AA.

 --------------------------------------
 Comment on WG response
 -------------------------------------
 I wasn't aware SC 2.3.2 was intended to ban natural phenomenon, but
since you have brought this to my attention, I feel that it is rather
absurd to have a W3C Recommendation that bans video of natural
phenomenon like lightning strikes from being presented on the web.
This is hardly likely to gain the ringing endorsement of the
scientific community.

 As to my general request for greater consideration to be given to
people who do not conform to "typical viewing" parameters, I accept
that the WG is not open for movement on this issue.

 With reference to your point about common video occurrences and some
movie effects, I will venture to suggest that sites with moving images
of the "sun shining through a row of trees" or "machine gun" fire are
out-numbered by orders of magnitude by sites with tacky flashing
stars, smiling graphics or advertisements. Maybe the WG response to my
comment says more about the composition and social/cultural tastes of
the Working Group than it does about improving the web experience for
people with impaired vision who are at risk of seizures.





 ----------------------------------------------------------
 Comment 11: labels and headings definition not sufficient
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0022.html
 (Issue ID: 2398)
 Status: VERIFIED / ACCEPTED
 ----------------------------
 Original Comment:
 ----------------------------

 The text of this criterion is, "Labels and headings are descriptive.
 (Level AA)." This definition is too short and does not sufficiently
 describe the intent of the criterion.

 Proposed Change:
 The Working Group should consider rewriting SC 2.4.6. For example;

 2.4.6 Descriptive Labels and Headings: Labels and headings are
 descriptive and allow the relationships between the different sections
 of web page content to be easily determined. (Level AA)

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 We have clarified SC 2.4.6 to read: "2.4.6 Labels Descriptive:
 Headings and labels describe topic or purpose."

 We have added the following sentences to Understanding 2.4.6 "Labels
 and headings do not need to be lengthy. A word or even a single
 character may suffice if it provides an appropriate cue to finding and
 navigating content."

 ----------------------------------------------------------
 Comment 12: provide greater support for people with cognitive,
 language or reading difficulties
 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0023.html
 (Issue ID: 2399)
 Status: VERIFIED / NOT ACCEPTED
 ----------------------------
 Original Comment:
 ----------------------------

 Like many others, I have argued in the past that WCAG 2.0 does not
 provide sufficient formal recognition of the importance of meeting the
 needs of people with cognitive, learning or language limitations. I
 believe this is still the case with the current Last Call Draft.

 Given the Working Group's obsession with testability when it relates
 to Success Criteria concerned with cognitive and learning difficulties
 (a requirement that does not appear to be so fervently demanded when
 it comes to other disabilities), I recognise that the Working Group is
 never going to accept a general notion that web content should use
 clear and simple language that is appropriate to the needs of the
 audience (similar to WCAG 1.0 " 14.1).

 However, within Guideline 3.1, I feel that more should be done to help
 ensure that people with cognitive, learning or language difficulties
 are able to access web content which can directly affect their health
 and liberty.

 The "Understanding SC 1.2.1 Captions" document appears to recognise
 that at least some "legal documents" and "instructional manuals" might
 need to contain non-text synchronised media in order to assist
 comprehension, however there is no explicit requirement to include
 this material. While the issue of ensuring text equivalents are
 provided for non-text content is well catered for in WCAG 2.0, very
 little is done to ensure assistance is provided for web users who have
 difficulties reading or interpreting text.

 The following suggested Success Criterion draws on the apparent
 acknowledgement in SC 3.3.4 that, with some web content the potential
 consequences of inaccessibility are greater. Even though I am not
 comfortable with the idea of associating cognitive, learning and
 language difficulties with reading ability, the suggested criterion
 uses the readability of "lower secondary education level" as a
 yardstick since it appears that this provides a degree of testability
 that is acceptable to the Working Group.

 Proposed Change:
 The Working Group should consider including the following new Level A
 Success Criterion for Guideline 3.1:

 3.1.* Understandable (Legal, Financial, Health): For Web pages that
 provide legal, financial and health instructions, warnings or
 regulations that are essential for the preservation of the
 individual's health and liberty, at least one of the following is
 true: (Level A)

 1. Readable: The text does not require a reading ability more advanced
 than lower secondary education level.

 2. Text alternative: An alternative simple language version with
 equivalent information that does not require a reading ability more
 advanced than lower secondary education level is also provided.

 3. Non-text alternative:  An alternative non-text version (for example
 audio or video) that contains equivalent information is also provided.

 ---------------------------------------------
 Response from Working Group:
 ---------------------------------------------

 We looked at this very carefully but the working group does not feel
 that it can require that legal documents, for example, can be required
 to be easy to read.   There are many reasons for the language used in
 these types of documents.  Also it is often not legal to have an
 alternate form of the document that a person would read that is
 different from what they are agreeing to.

 Regarding the audio form, we do require at level A that all documents
 have a text form that is readable by assistive technologies.   There
 are also free utilities on the web and built into popular operating
 systems that will read a text document aloud.
Received on Monday, 24 March 2008 14:20:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:25 GMT