- From: Shawn Henry <shawn@w3.org>
- Date: Wed, 26 Mar 2008 07:45:09 -0500
- To: "EOWG (E-mail)" <w3c-wai-eo@w3.org>, public-comments-WCAG20@w3.org
Dear WCAG WG,
EOWG accepts your resolutions below.
("WCAG 2.0 is great as is... Lets deliver it.: I have my opinions about things in WCAG 2.0 that could be better, but at this point I think they are hair splitting. In some areas I disagree with the responses, but not enough to argue it. And, I might be wrong. So, I think it is time to wrap 2.0 in a bow and send it to the universe."[1] "I agree. Let's move forward!"[2])
We are excited that you are progressing WCAG 2.0 closer to becoming a W3C Recommendation, Web standard. Congratulations.
Regards,
~Shawn Henry for EOWG[3]
[1] http://www.w3.org/2002/02/mid/47E3F19F.4000204@csulb.edu;list=w3c-wai-eo
[2] http://lists.w3.org/Archives/Public/w3c-wai-eo/2008JanMar/0170.html
[3] http://www.w3.org/WAI/EO/
Loretta Guarino Reid wrote:
> Dear EOWG,
>
> 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: Allow users to filter out HTML techniques
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0118.html
> (Issue ID: 2567)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> suggested revision: allow users to filter out HTML techniques
>
> rationale: lets users filter out a bunch of info that is not necessary
> in certain use cases, e.g., wanting to look up only multimedia or CSS
> related issues. (note that several EOWG participants tried to do this
> and were overwhelmed with the number of techniques still listed.)
>
> Proposed Change:
> Allow users to filter out HTML techniques.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> The way the document is currently set up, it breaks if we try to do
> this. We will add this suggestion to a to-do list for future
> consideration. In the meantime, authors can use the listing of
> techniques by technology to view all of the techniques available for a
> given technology.
>
> ----------------------------------------------------------
> Comment 2: List all contributors to WCAG 2.0
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0120.html
> (Issue ID: 2569)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> Suggest including *everyone* who has made a contribution to WCAG2.0 -
> 1500 comments?
>
> Rationale: Gives strong authority to the document.
>
> Proposed Change:
> Suggest including *everyone* who has made a contribution to WCAG2.0,
> including those who submitted comments. Could be pulled off into
> another page.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We would have to get permission from everyone to do this. Some who
> have commented may not want their names on the document.
>
> We will look into creating a separate page on the Web site to list all
> of the commenters.
>
> ----------------------------------------------------------
> Comment 3: Typos in Programmatically determiend
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0121.html
> (Issue ID: 2570)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Definition - Programmatically determiend
>
> Spelling error: determined
>
> Capitalisation inconsistency: should be lower case for consistent capitalisation
>
> Proposed Change:
> fix spelling typo and make lower case
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Thank you. These typos have been fixed.
>
> ----------------------------------------------------------
> Comment 4: changes of context definition
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0122.html
> (Issue ID: 2571)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Definition - changes of context
>
> Should these not be examples rather than a complete definition? - I
> can't think of another context, but doesn't mean that one won't be
> developed eventually.
>
> Proposed Change:
> provide a complete definition, and use what's there as examples
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have revised the definition as follows:
>
> changes of context
> major changes in the content of the Web page that, if made without
> user awareness, can disorient users who are not able to view the
> entire page simultaneously
>
> Changes in context include changes of:
>
> 1. user agent;
> 2. viewport;
> 3. focus;
> 4. content that changes the meaning of the Web page.
>
> Note: A change of content is not always a change of context.
> Changes in content, such as an expanding outline or dynamic menu, do
> not necessarily change the context, unless they also change one of the
> above (e.g. focus)
>
> Example: Opening a new window, moving focus to a different
> component, going to a new page (including anything that would look to
> a user as if they had moved to a new page) or significantly
> re-arranging the content of a page are examples of changes of context.
>
> ----------------------------------------------------------
> Comment 5: Clarify what 'which is optional' applies to
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0123.html
> (Issue ID: 2572)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Current wording: "This section lists requirements for conformance to
> WCAG 2.0 as well as information about how to make conformance claims,
> which are optional. It also introduces..."
>
> Suggested revision: "This section lists requirements for conformance
> to WCAG 2.0. It also gives information about how to make conformance
> claims, which are optional, and introduces..."
>
> Rationale: it could be legally argued that it the current form leaves
> it ambiguous as to whether the phrase 'which is optional' applies to
> the second phrase of the sentence, or the first and second. We don't
> think that this is a comprehension problem, yet a potential legal one.
>
> Proposed Change:
> Suggested revision: "This section lists requirements for conformance
> to WCAG 2.0. It also gives information about how to make conformance
> claims, which are optional, and introduces..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated the text to read as follows:
>
> This section lists requirements for conformance to WCAG 2.0. It also
> gives information about how to make conformance claims, which are
> optional. Finally, it describes what it means for Web content
> technologies to be accessibility-supported, since only
> accessibility-supported technologies can be relied on for conformance.
> Understanding Conformance includes further explanation of the
> accessibility-supported concept.
>
> ----------------------------------------------------------
> Comment 6: Remove rationale from Guideline 1.1 text
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0124.html
> (Issue ID: 2573)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> current wording: "Guideline 1.1 Text Alternatives: Provide text
> alternatives for any non-text content so that it can be changed into
> other forms people need, such as large print, braille, speech, symbols
> or simpler language"
>
> suggested revision: remove the extra text
>
> Rationale: "so that it can be changed into other forms people need,
> such as large print, braille, speech, symbols or simpler language" is
> the rationale behind the guideline and therefore should not be
> included in the guideline text for several reasons, including:
>
> - the rationale isn't included in the text of the other guidelines or SC
>
> - the extra wording makes it more complex to parse the guideline text
>
> - it could encourage the guideline to be interpreted to be restricted
> to the cases listed
>
> - it is easier to skim the documents without the additional rationale
> in the guideline text
>
> - (and, many people know this already)
>
> Proposed Change:
> "Guideline 1.1 Text Alternatives: Provide text alternatives for any
> non-text content"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> You are correct that this guideline is different than most of the
> others in that it includes explanatory text. This was done because
> the guideline is so important across disabilities and is so often
> misunderstood as to its purpose. The understanding document does cover
> this, but these guidelines appear in many places by themselves. The
> text is important to understanding not only the guideline but the
> success criteria under it.
>
> We could have written it with "such that" rather than "so that" and it
> would then have been clearer that the text must allow all these things
> to be done. But, it was harder to read with that language.
>
>
> ----------------------------------------------------------
> Comment 7: Link 'metadata'
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0125.html
> (Issue ID: 2574)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> current wording: "Metadata may assist users in finding content most
> suitable for their needs."
>
> suggested revision: "_Metadata_ may assist users in finding content
> most suitable for their needs." with "metadata" linked to a definition
> or location where it is explained.
>
> Rationale: metadata is a technical term/jargon and needs linking to a
> definition or explanation
>
> Proposed Change:
> "_Metadata_ may assist users in finding content most suitable for
> their needs." with "metadata" linked to a definition or location where
> it is explained.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have added the link as proposed.
>
> ----------------------------------------------------------
> Comment 8: "Item Number': Abstract. clarify with commas
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0126.html
> (Issue ID: 2575)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> current wording: "Guidance about satisfying the Success Criteria in
> specific technologies as well as general information about
> interpreting the Success Criteria are provided in separate documents."
>
> suggested revision: add commas
>
> rationale: makes this sentence easier to parse.
>
> Proposed Change:
> "Guidance about satisfying the Success Criteria in specific
> technologies, as well as general information about interpreting the
> Success Criteria, are provided in separate documents."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have inserted the commas as proposed.
>
> ----------------------------------------------------------
> Comment 9: Add header to first page
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0127.html
> (Issue ID: 2576)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Add the header that is on the subpages to the first page
> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>
>
> Rationale: Provide consistent navigation and design across different
> Web pages in the same document. Reinforce that the pages are related.
>
> Proposed Change:
> Include the header that is on the subpages on the first page
> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/> (with "Understanding WCAG
> 2.0" at the top left and 'buttons' for Intro and Next...)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> The subtitle (actually running head title) on the sub pages is on the
> first page - but it is the title of the first page. We are not
> repeating it as a running head on the main page because it would mean
> the title would appear twice at the top of the page - especially for
> screen reader users this could be confusing to hear.
>
> ----------------------------------------------------------
> Comment 10: Change "accessibility supported" to "accessibility-supporting"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0129.html
> (Issue ID: 2577)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Several in EOWG continue to feel strongly that it should be
> "accessibility-supporting technologies". Here are two perspectives on
> this issue:
>
> What is doing what to what? I *think* it's that technologies such as
> HTML and CSS are supporting accessibility in that they give structures
> that are available to AT to provide data about relationships within
> content.
>
> <excerpt>'Here is how I think the WCAG WG is thinking of it:
> "Accessibility supporting" would talk about what the technology does.
> That is, it supports accessibility. "Accessibility supported" refers
> to what has been done to (or is true of) a technology. That is, that
> there is accessibility support FOR the technology. We mean the latter
> not the former. So "accessibility supported" would be the correct term
> and would be hyphenated whenever used as an adjective.'</excerpt>
>
> So let's unpack this. Is it true that HTML is accessibility-supported?
> That is the same as saying that HTML is supported by accessibility.
> I'm not sure that "HTML is supported *by* accessibility" is a
> meaningful phrase. "HTML or CSS provides support for AT" would be
> meaningful. But it doesn't do what we want to do, which is to
> differentiate between technologies that remove accessibility barriers
> and technologies that don't.
>
> Consider a fictional new content delivery technology, let's call it
> PEBKAC. PEBKAC has some integral accessibility features, but these are
> not supported by users' assistive technologies, nor by current
> browsers and other user agents. Where is the 'accessibility'? Is it
> sitting in PEBCAK, unsupported by AT? Or is it sitting in the AT,
> unsupported by PEBKAC? Or is it an emergent property of the link
> between the two?
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Yes - HTML is supported by accessibility tools (that is, it is
> supported by assistive technology and access features in user agents).
> The key to the guidelines is that the technologies that are used will
> work with and are supported by assistive technologies and access
> features in other user agents. If they are not supported, then users
> cannot access the information encoded in the technologies even if the
> technologies support accessibility (e.g. provide ways for AT to access
> them). It is the support by assistive technology that makes the
> technologies and the content in them usable by people with
> disabilities.
>
> In your example, PEBKAC is accessibility-supporting but it is not
> accessibility-supported because there is no assistive technology that
> supports it.
>
>
--
Shawn Lawton Henry, W3C Web Accessibility Initiative (WAI)
about: http://www.w3.org/People/Shawn/
phone: +1-617-395-7664
e-mail: shawn@w3.org
Received on Wednesday, 26 March 2008 12:45:51 UTC