- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 11 Mar 2008 01:18:17 +0000
- To: public-comments-WCAG20@w3.org
Just to confirm that, beyond the concerns I raised separately for issues
2462 and 2512, I'm happy to say that I'm satisfied with the responses
and resolutions outlined by the group for all other issues.
P
Loretta Guarino Reid wrote:
> Dear Patrick Lauke,
>
> 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: Combine "usable in general" and "older individuals"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0000.html
> (Issue ID: 2453)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> The 2nd para sounds a bit stilted and, in the second half, seems to
> jump from users with disabilities, to users in general, to degrees of
> disability, and then back to (general)/older users.
>
> Proposed Change:
> Reorder sentences and merge the two general ones.
>
> ...and neurological disabilities. Although these guidelines cover a
> wide range...and combinations of disabilities. These guidelines also
> make content more usable by older individuals with changing abilities
> due to aging, and often improve usability for all users in general.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Good suggestion. We have included your suggestion as proposed.
>
> ----------------------------------------------------------
> Comment 2: "Webmasters"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0001.html
> (Issue ID: 2454)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> The term "Webmasters" is certainly outdated, and often today just
> refers to the technical maintainer of a server.
>
> Proposed Change:
> Replace "Webmasters" with "Web designers and developers"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated this section as proposed.
>
> ----------------------------------------------------------
> Comment 3: Metadata sentence right at the end
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0002.html
> (Issue ID: 2455)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> This last sentence on metadata comes almost out of the blue, and seems
> almost an afterthought. Also, it doesn't explain what metadata this
> might actually be...what format? Additionally, are there actual tools
> deployed today that take advantage of any such metadata, whatever its
> format?
>
> Proposed Change:
> Either remove the sentence, or take this opportunity to clarify with a
> few more sentences in a separate paragraph WHAT metadata, HOW it
> should be implemented, and what concrete uses there are today?
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> That sentence was added in response to specific requests for an
> indication of the role that metadata can play. We have added a link
> to the word METADATA that leads to a description such as you ask for
> that is in the Understanding WCAG 2.0 Document.
>
> ----------------------------------------------------------
> Comment 4: Missing full stop
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0003.html
> (Issue ID: 2456)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> A full stop is missing in "Accessibility Supported" explanation
>
> Proposed Change:
> "...technologies can be used to conform to WCAG 2.0 Success
> Criteria*.* Technologies that are..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Thank you. This typo has been fixed.
>
> ----------------------------------------------------------
> Comment 5: Add reference to 1.2.1
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0005.html
> (Issue ID: 2457)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> The note for 1.2.3 already mentions prerecorded synchronised media,
> but it may be worth adding the explicit reference back to 1.2.3 and
> dropping the "in WCAG 2.0."
>
> Proposed Change:
> "...requirements for prerecorded synchronised media (see 1.2.1)."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have removed the note as a result of other comments and a
> reorganization of some the success criteria in guidelines 1.1 and 1.2.
> Note that an explicit reference to 1.2.1 (now 1.2.2) was not included
> since many of the success criteria under guideline 1.2 also relate to
> prerecorded synchronized media.
>
> ----------------------------------------------------------
> Comment 6: Add reference to 1.4.1
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0006.html
> (Issue ID: 2458)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> Although color is treated in 1.4, it is nonetheless a sensory
> characteristic. Should it be added to the list, with a note
> referencing 1.4.1?
>
> Proposed Change:
> "...components such as shape, *color,* size, visual location,
> orientation or sound. (Level A)
>
> Note: issues specific to color are covered in Guideline 1.4 (see
> specifically 1.4.1)." (or similar)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have added the following note to Success Criterion 1.3.3:
>
> Note: For requirements related to color, refer to Guideline 1.4.
>
> ----------------------------------------------------------
> Comment 7: Awkward wording in SC 1.4.2
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0007.html
> (Issue ID: 2459)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Awkward wording
>
> Proposed Change:
> "...audio volume which can be set *independently* from the *overall*
> system volume level..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated Success Criterion 1.4.2 as proposed.
>
> ----------------------------------------------------------
> Comment 8: Clarification of note / awkward phrasing
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0008.html
> (Issue ID: 2460)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> "one quarter as loud" sounds stilted. also, the note may benefit from
> being prefaced by something like "In simple terms," or "As a rough
> measure," or "As a rule of thumb,"...
>
> Proposed Change:
> Preface note with "In simple terms," or "As a rough measure" or "As a
> rule of thumb," followed by "sound that meets this requirement will be
> approximately four times quieter than the foreground speech content."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have revised the note to read as follows:
>
> In general, background sound that meets this requirement will be
> approximately four times quieter than the foreground speech content.
>
> ----------------------------------------------------------
> Comment 9: 80 characters?
> Source: http://www.w3.org/mid/20080201003754.9BF965F70B@stu.w3.org
> (Issue ID: 2462)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> "width is no more than 80 characters" sounds arbitrary...do you
> actually intend to talk about "line length", which is not necessarily
> bound to just the number of characters, but can also be influenced by
> the size/shape of the typeface used?
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> It is somewhat arbitrary. We could have chosen 72, for example, which
> is another common line length. We chose 80 to be a bit more relaxed
> and because that is a standard in computers where as 72 is more
> standard in typewriters. The goal is to limit line length from being
> too wide. The number of characters is the only thing that can be
> reliably measured.
>
> ----------------------------------------------------------
> Comment 10: aligned on both left and right
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0011.html
> (Issue ID: 2463)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "text is not aligned on both the left and the right"
>
> generally, this is referred to as "justified"
>
> Proposed Change:
> "text is not justified (flush both left and right)"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated the bullet to read, "text is not justified (aligned to
> both the left and the right margins)."
>
> ----------------------------------------------------------
> Comment 11: line spacing
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0012.html
> (Issue ID: 2464)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "line spacing" is generally referred to as "leading", but its usage
> may admittedly be less known outside of proper graphic design circles
>
> Proposed Change:
> "leading (line spacing) is at least..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated this bullet to read, "line spacing (leading) is at least..."
>
> ----------------------------------------------------------
> Comment 12: what if it's not the author's fault?
> Source: \"line spacing\" is generally referred to as \"leading\", but
> its usage may admittedly be less known outside of proper graphic
> design circles (Issue ID: 2465)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> a known issue with flash in firefox is the fact that the plugin traps
> the keyboard (and can even prevent tabbing *into* the flash movie),
> while the same plugin works as expected in IE. where does an author
> stand in this situation, where it's the UA's fault?
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> In a case like this - where it is a shortcoming of one browser, but
> not a problem with other browsers - we would say that it was a
> reasonable assumption by the author that the user could exit. The
> Working Group would encourage the author to provide an additional
> redundant function which allows the user to exit that they know does
> work in most browsers.
>
> Refer to Understanding Accessibility Support for additional information.
>
> ----------------------------------------------------------
> Comment 13: GL 2.4: "with disabilities"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0014.html
> (Issue ID: 2466)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> this Guideline and Guideline 2.4, are the only ones that explicitly
> mention users "with disabilities". why are they being singled out? are
> the guidelines not just as valid for "users in general, and older
> individuals..." like it says in the intro?
>
> Proposed Change:
> remove "with disabilities" from the wording of the guideline
> completely (and in the ToC, of course)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have have changed "users with disabilities" to "users" in 2.2 and 2.4.
>
> ----------------------------------------------------------
> Comment 14: "with disabilities", take two
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0015.html
> (Issue ID: 2467)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> this Guideline and Guideline 2.2, are the only ones that explicitly
> mention users "with disabilities". why are they being singled out? are
> the guidelines not just as valid for "users in general, and older
> individuals..." like it says in the intro?
>
> Proposed Change:
> remove "with disabilities" from the wording of the guideline
> completely (and in the ToC, of course)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have have changed "users with disabilities" to "users" in 2.2 and 2.4.
>
> ----------------------------------------------------------
> Comment 15: arbitrary values?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0016.html
> (Issue ID: 2468)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> "Extend: ... at least ten times or
> ...
>
> 20 Hour Exception: the time limit is longer than 20 hours."
>
> ten times and 20 hours seem completely arbitrary. why were they
> chosen? if they *are* arbitrary, this needs to be clarified with
> appropriate wording.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> The 10 times extension was chosen to increase the response tail by 10
> times to pick up those who need more time, but to limit the total
> number of repeats so that it is not endless. The number 10 harmonizes
> WCAG with other international standards.
>
> Twenty hours was chosen in consultation with industry to allow
> sessions to be closed in less than 24 hours to clear their servers -
> even if they have no way to push a warning to users - but to allow
> people who might need a full day to complete actions to have the time.
>
> ----------------------------------------------------------
> Comment 16: flashing dependent on size?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0018.html
> (Issue ID: 2470)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> As with 2.3.1 (see my previous comment on that too), i believe there
> is still a size limitation (or is even a single pixel subject to
> this?)
>
> Proposed Change:
> Add relevant wording about the size of the flashing area (relating it
> to percent of the field of view or similar). Also include in the
> related "Understanding..." bit.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Whereas 2.3.1 uses the term "general flash and red flash thresholds,"
> which includes all of the metrics size of the area, 2.3.2 has not
> such limits. As a result, even a single pixel flashing would violate
> 2.3.2.
>
> The following has been added to understanding to make this clear.
>
> "Whereas 2.3.1 allows flashing if it is dim enough or has a small
> enough area, 2.3.2 does not allow flashing greater than 3 per second
> regardless of brightness or size. A single pixel would violate 2.3.2.
> The intent is to guard against flashing larger than a single pixel,
> but since an unknown amount of magnification or high contrast setting
> may be applied, the prohibition is against any flashing."
>
> Because the definitions are normative, these metrics are also normative.
>
> ----------------------------------------------------------
> Comment 17: SC 2.4.5: sweeping generalisation?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0019.html
> (Issue ID: 2471)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> The wording seems far too general. Does this apply even to a site with
> only 3 or 4 pages? How about a site consisting of a single page?
>
> Proposed Change:
> Clarify *when* this applies (and no *arbitrary* numbers of pages,
> please, unless the wording makes it clear it's only an arbitrary
> figure)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> A site consisting of a single page is not a set of Web pages, so
> success criterion 2.4.5 would be satisfied in this case.
>
> We have added a sufficient technique to 2.4.5, "Linking to all of the
> pages on the site from the home page so that it can serve both as a
> home page and as a site map."
>
> In addition, we have added the following paragraph to the
> Understanding document to clarify that there are techniques that may
> be appropriate for small sites.
>
> "Even small sites should provide users some means of orientation. For
> a three or four page site, with all pages linked from the home page,
> it may be sufficient simply to provide links from and to the home page
> where the links on the home page can also serve as a site map."
>
> ----------------------------------------------------------
> Comment 18: dependent on UA?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0020.html
> (Issue ID: 2472)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> Surely this is dependent for the most part on the UA itself? Authors
> should not have to worry, *unless* they're actively overriding focus
> (e.g. via CSS styling), in which case the wording needs to be changed.
> Specifically setting very visible additional focus hints via CSS can
> certainly improve usability/accessibility, but this is only in
> addition to what the UA already does (and if the UA complies with
> UAAG, even its default should be enough not to be a barrier to users)
>
> Proposed Change:
> If this is more along the lines of authors actively overriding focus
> (e.g. via CSS styling), the wording needs to be changed...maybe
> "Authors should not override or suppress any default focus
> indicators". This would also require a rewrite of the relevant "How to
> meet" and "Understanding"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> SC 2.4.7 is often satisfied by the user agent with no special action
> required by the author. The first sufficient technique listed, "G149:
> Using user interface components that are highlighted by the user agent
> when they receive focus", describes this situation.
>
> However, when authors create custom controls, the custom controls may
> not inherit the user agent's built-in support for focus highlighting.
> In this case, it is the author's responsibility to ensure that there
> is some visible indication when the custom control has keyboard focus.
>
> Because there are also Web pages where authors actively remove the
> focus highlight provided by the user agent, this success criterion is
> needed for the content itself.
>
> ----------------------------------------------------------
> Comment 19: so headings are optional then at anything below AAA?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0021.html
> (Issue ID: 2473)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> as headings (thinking HTML here) are absolutely essential in conveying
> document structure, i'm wondering why this SC is relegated to AAA. i'd
> have seen this more at AA at least. (compare with WCAG 1 checkpoint
> 3.5)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We had a number of comments that mistake the purpose of success
> criterion 2.4.10 and success criterion 1.3.1.
>
> Success criterion 1.3.1, which is at level A, requires that anything
> that looks like a heading is marked up as a heading.
>
> Success criterion 2.4.10 says that anywhere you could use a heading,
> you have to insert one. This provision is included at level AAA
> because it cannot be applied to all types of content. It is often not
> possible to insert headings. For example, if you are posting a
> pre-existing document, you do not have the ability to insert headings
> that an author did not include in the original document. Or, if you
> have a long letter, it would often cover different topics, but putting
> headings into a letter would be very strange.
>
> However, if a document can be broken up into sections with headings,
> it facilitates both understanding and navigation. For this reason, it
> is a success criterion. But, because it can't always be done (or be
> appropriate) it is at level AAA.
>
> We have added this explanation to Understanding SC 2.4.10.
>
> Failure F2 also speaks to this:
>
> F2: Failure of Success Criterion 1.3.1 due to using changes in text
> presentation to convey information without using the appropriate
> markup or text.
>
> ----------------------------------------------------------
> Comment 20: ambiguous if not clear from context already?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0022.html
> (Issue ID: 2474)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> with the current wording, it sounds like *any* word that could be
> ambiguous needs to be covered by a mechanism. however, i assume this
> implies "yes, there may be different meanings for this word, but only
> specify pronunciation *if* the current context doesn't disambiguate
> it".
>
> Proposed Change:
> change wording
>
> "...where meaning is ambiguous (even in the current context) without
> knowing the pronunciation"
>
> or add a note
>
> "this SC does not cover situations in which the specifically intended
> meaning of the word is clear from the existing context"
>
> also consider modifying "How to meet..." and "Understanding..." accordingly.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> What you suggest is what the sentence is intended to mean. So we have
> changed the SC to read:
>
> 3.1.6 Pronunciation: A mechanism is available for identifying specific
> pronunciation of words where meaning of the words, in context, is
> ambiguous without knowing the pronunciation. (Level AAA)
>
> ----------------------------------------------------------
> Comment 21: "well formed"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0023.html
> (Issue ID: 2475)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> use of "well formed" could help shorten this, or at least clarify with
> a commonly-used term from the html/xml world.
>
> Proposed Change:
> "...Content implemented using markup languages *is /well formed/ - it*
> has elements with..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> It is true that the guidelines now essentially require that content in
> markup languages be well formed. However, exact parsing requirements
> vary amongst markup languages, and most non XML-based languages do not
> explicitly define requirements for well formedness. Therefore, it was
> necessary to be more explicit in the success criterion in order to be
> generally applicable to markup languages. Because the term "well
> formed" is only defined in XML, and because end tags are sometimes
> optional, valid HTML does not require well formed code. Therefore, we
> felt we could not use that term.
>
> We have added a note to the understanding document to help clarify this:
>
> Note: The concept of "well formed" is close to what is required here.
> However, exact parsing requirements vary amongst markup languages, and
> most non XML-based languages do not explicitly define requirements for
> well formedness. Therefore, it was necessary to be more explicit in
> the success criterion in order to be generally applicable to markup
> languages. Because the term "well formed" is only defined in XML, and
> (because end tags are sometimes optional) valid HTML does not require
> well formed code, the term is not used in this success criterion.
>
> ----------------------------------------------------------
> Comment 22: Awkward wording
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0025.html
> (Issue ID: 2477)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Awkward, potentially confusing wording?
>
> Proposed Change:
> "(Conformance is not possible at *a particular* level if *any page* in
> the sequence *does* not conform at that level.)"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have revised the sentence as proposed.
>
> ----------------------------------------------------------
> Comment 23: Optional components and the hint of metadata
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0026.html
> (Issue ID: 2478)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "1. ... that consumers can use, preferably machine-readable metadata."
>
> this seems to suggest that users can already consume metadata today.
> are there any such tools widely available that take advantage of
> metadata? if so, what are they?
>
> 5. and 6. also talk about metadata...however fail to suggest, or even
> mention, any such metadata standard or format.
>
> Proposed Change:
> Either add hard information on metadata (e.g. currently available
> formats/vocabularies), or drop the whole metadata talk (including the
> little sentence in the intro)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> There are currently metadata technique titles listed in the Quick
> Reference and Understanding documents. Currently, they are advisory
> due to lack of support in AT and other tools. We expect this to change
> over the years - and awareness is important to progress in this area.
>
> Rather than including more detail about metadata as a concept, we
> provide a link to more complete resources in the "Understanding
> Metadata" section of the understanding document.
>
> ----------------------------------------------------------
> Comment 24: awkward phrasing - Statement of partial conformance
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0058.html
> (Issue ID: 2509)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> Proposed Change:
> "...article that allows users to add comments, or applications..."
> (remove "to the bottom", which is irrelevant)
>
>
>
> "...such as portals and news sites, or sites that automatically insert
> content from other sources over time."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Thank you. We have included these wording suggestions as proposed.
>
> ----------------------------------------------------------
> Comment 25: abbreviation refers to "organization"?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0059.html
> (Issue ID: 2510)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> the whole "...has not been rejected by the organization that it refers
> to..." seems very out of place, and is not applicable to apply to all
> types of abbreviations
>
> Proposed Change:
> remove the sentence, as it seems wholly irrelevant.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> There are companies like Ecma where, before 1994, ECMA was an
> initialism for "European Computer Manufacturers Association," but when
> the company changed it's name it kept "Ecma" as a trademark for
> historical purposes, but no longer recognized it as an abbreviation.
>
> But, as you have highlighted, if it is not, then it is not and the
> phrase cited is not needed. We have therefore moved the phrase into an
> explanatory note.
>
> The definition and note now read as follows:
>
> abbreviation
>
> shortened form of a word, phrase, or name where the abbreviation
> has not become part of the language
>
> Note: There are some companies that have adopted what used to be an
> initialism as their company name. In these cases, the new name of the
> company is the letters (for example, Ecma) and the word is no longer
> considered to be an abbreviation.
>
> ----------------------------------------------------------
> Comment 26: Statement of partial conformance - both cases - awkward
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0060.html
> (Issue ID: 2511)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "In both of these cases, it is not possible..."
>
> Proposed Change:
> change to "In these cases, it is not possible..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have incorporated your suggestion as proposed.
>
> ----------------------------------------------------------
> Comment 27: Statement of partial conformance - immediately?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0061.html
> (Issue ID: 2512)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> In point 1, I think the two instance of "immediately" are simply
> unrealistic. What is "immediately"? It's just not possible.
>
> Proposed Change:
> either remove the two instances of "immediately", or change wording to
> something more realistic ("within a reasonable timescale"?)
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have removed "immediately" and added "within two business days."
> This way, it is clear that the intent for claims of partial
> conformance is that corrections are made as a regular monitoring
> process encounters non-conforming content.
>
> ----------------------------------------------------------
> Comment 28: accessibility supported - users' assistive technologies
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0063.html
> (Issue ID: 2514)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> awkward having "users' assistive technologies" 3 times in point 1.
>
> Proposed Change:
> remove "users'" and just say "assistive technologies", unless I'm
> missing a fundamental reason why you're making a point of saying that
> it's *users'* AT.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> As you guessed, the word "users'" has significance. The key here is
> that the technologies need to be accessible not to *all assistive
> technology,* but to the assistive technologies of the users of the
> site.
>
> For example, if the site is an *intranet* and used only within a
> company, then only the technologies used within the company would need
> to be supported. If it were a public site, then a wider range of
> assistive technologies would need to be supported.
>
> ----------------------------------------------------------
> Comment 29: activity where moving, blinking...
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0064.html
> (Issue ID: 2515)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> the explanation is lengthy, and doesn't really say more than the term
> it tries to clarify. maybe just focus on writing something that
> explains what's meant by "essential"
>
> Proposed Change:
> just explain "essential" as "which, if removed, would fundamentally
> change the functionality of the content"
>
> ---------------------------------------------
> 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 30: assistive technology - stray word
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0065.html
> (Issue ID: 2516)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "Example: Examples of assistive technologies that are important in the
> context of this document include the following:"
>
> Proposed Change:
> Remove the first "Example: "
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Thank you. We have removed the duplicate text.
>
> ----------------------------------------------------------
> Comment 31: blink vs flash
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0066.html
> (Issue ID: 2517)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> the distinction between "blink" and "flash" still isn't clear. is
> blink simply a special case of "flash"?
>
> Proposed Change:
> either clarify how the two differ, or merge their definitions
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Blink and Flash are not mutually exclusive. Some blinking can cause
> seizure while other blinking would not. They are two overlapping
> circles in a Venn diagram.
>
> We have added links to the definition of "flash" in 2.3.1 and 2.3.2.
>
> This is explained in greater detail in the understanding documents for
> 2.2.2 and 2.3.1:
>
> Note: The terms BLINKING and FLASHING can sometimes refer to the same content.
>
> * "Blinking" refers to content that causes a distraction problem.
> Blinking can be allowed for a short time as long as it stops (or can
> be stopped)
>
> * "Flashing" refers to content that can trigger a seizure (if it is
> more than 3 per second and large and bright enough). This cannot be
> allowed even for a second or it could cause a seizure. And turning the
> flash off is also not an option since the seizure could occur faster
> than most users could turn it off.
>
> * Blinking usually doesn't occur at speeds of 3 per second or more,
> but it can. And if blinking occurs faster than 3 per second it would
> also be considered a flash.
>
> ----------------------------------------------------------
> Comment 32: captions - awkward wording
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0067.html
> (Issue ID: 2518)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> "text presented and synchronized with synchronized media..."
>
> Proposed Change:
> change to "text used in synchronized media..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have revised the definition of captions as follows:
>
> captions
>
> synchronized visual or text equivalent for both dialog and
> non-dialog audio information needed to understand the media content
>
> Note 1: Captions are similar to dialog-only subtitles except captions
> convey not only the content of spoken dialog, but also equivalents for
> non-dialog audio information needed to understand the program content,
> including sound effects, music, laughter, speaker identification and
> location.
>
> Note 2: Closed Captions are equivalents that can be turned on and off
> with some players.
>
> Note 3: Open Captions are any captions that cannot be turned off. For
> example, if the captions are visual equivalent images of text embedded
> in video.
>
> Note 4: Captions should not obscure or obstruct relevant information
> in the video.
>
> Note 5: In some countries, captions are called subtitles.
>
> Note 6: Audio descriptions can be, but do not need to be, captioned
> since they are descriptions of information that is already presented
> visually.
>
> ----------------------------------------------------------
> Comment 33: conforming alternative version - awkward wording
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0068.html
> (Issue ID: 2519)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "4. for which one at least of the following is true:"
>
> also, isn't point c just a special case of b?
>
> Proposed Change:
> change to "4. for which at least one of the following is true:"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Yes, that was a typo. The word "one" was misplaced.
>
> No, "c" is not a subset of "b". One is about *the* conforming
> alternative page.
> The other is about *a* conforming page that links to *the* conforming
> alternative page.
>
> For example, a landing page that contains links to both the conforming
> and non-conforming versions would satisfy case "c", but not case "b".
>
> ----------------------------------------------------------
> Comment 34: contrast ratio - generalised copy
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0098.html
> (Issue ID: 2548)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> this just mentions foreground/background color, but not adjacent
> color. for clarity, it may be worth dropping the "of the foreground or
> background" bit altogether
>
> Proposed Change:
> for clarity, it may be worth dropping the "of the foreground or
> background" bit altogether
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have removed foreground and background from the basic definition of
> contrast. It is now only in the notes talking about how to apply it.
>
> See http://www.w3.org/WAI/GL/WCAG20/#contrast-ratiodef
>
> ----------------------------------------------------------
> Comment 35: extended audio - clarification in note
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0099.html
> (Issue ID: 2549)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> note could be expanded for clearer understanding
>
> Proposed Change:
> at the end of the note, add ". and the pauses between dialog/narration
> are too short."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have added your proposed text to the end of the note.
>
> ----------------------------------------------------------
> Comment 36: flash
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0100.html
> (Issue ID: 2550)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> does this need any further clarification of the size of the area that flashes?
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> In the definition of general flash and red flash thresholds, the size
> is defined in terms of angle of vision. Specific information about
> key application areas is also provided in that definition. If you have
> suggestions for information that would also be helpful, please send
> them along.
>
> ----------------------------------------------------------
> Comment 37: general flash and red threshold - confusing jargon?
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0101.html
> (Issue ID: 2551)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> this section introduces a lot of specific jargon and technical wording
> ("steradians") and unqualified measures ("0.1 degrees" ... of what?")
>
> Proposed Change:
> clarify measures and avoid jargon
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have clarified the .1 degree. A steradian is the accurate term to
> use for this provision, which is very technical in nature. Wherever
> possible, we also provide a plainer language equivalent. (in the case
> of steradians, we included a parenthetical which describes in in terms
> of percent of visual field).
>
> Note that this particular provision can only be evaluated using the
> simple test (less than 3 flashes per second) which is very simple - or
> by using a tool. The exact technical language is used to make tool
> making more accurate and technically clear.
>
> ----------------------------------------------------------
> Comment 38: navigated sequentially
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0102.html
> (Issue ID: 2552)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> mention of "keyboard"...but this should possibly be expanded to
> "keyboard interface"
>
> Proposed Change:
> replace "using the keyboard" with "using a keyboard interface"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have included your proposed change and linked the updated text to
> the definition of "keyboard interface."
>
> ----------------------------------------------------------
> Comment 39: non-text content
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0103.html
> (Issue ID: 2553)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "leetspeak (which is character substitution)" sounds awkward
>
> Proposed Change:
> replace with "leetspeak (which *uses* character substitution)"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated the text as proposed.
>
> ----------------------------------------------------------
> Comment 40: programmatically determined / programmatically determinable
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0105.html
> (Issue ID: 2554)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> this comes after "programmatically determined (programmatically
> determinable) link content"
>
> Proposed Change:
> move above/before "programmatically determined (programmatically
> determinable) link content" definition
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have reordered and simplified the defined terms to
> "programmatically determined (programmatically determinable)" and
> "programmatically determined link context."
>
> ----------------------------------------------------------
> Comment 41: programmatically determiend - typo
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0106.html
> (Issue ID: 2555)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> typo in "determiend"
>
> Proposed Change:
> change to "determined"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Thank you. We have corrected this typo.
>
> ----------------------------------------------------------
> Comment 42: real-time event
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0107.html
> (Issue ID: 2556)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> mentions "fantasy world" - sounds a bit strange to single out WoW and similar?
>
> Proposed Change:
> replace with "virtual world"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated the example as proposed.
>
> ----------------------------------------------------------
> Comment 43: role
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0108.html
> (Issue ID: 2557)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "text or a number" the a is superfluous
>
> Proposed Change:
> replace with "text or number"
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated the definition as proposed.
>
> ----------------------------------------------------------
> Comment 44: set of Web pages - clarify
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0109.html
> (Issue ID: 2558)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "collection of Web pages that share a common purpose..."
>
> worth mentioning these pages should also be on the same site (i.e. not
> same purpose pages on different sites)?
>
> Proposed Change:
> replace with "collection of Web pages *on the same site* that share a
> common purpose..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Some sets of Web pages may not be on the same site. For example, the
> last step in a set of Web pages on a shopping site may appear on a
> separate site.
>
> ----------------------------------------------------------
> Comment 45: set of Web pages - unnecessarily convoluted
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0110.html
> (Issue ID: 2559)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "and that are created...organization"
>
> sounds awkward, not always true - thinking of multi-author
> environments - and addressed if my previous point is considered
> (limiting the set of Web page to the same site)
>
> Proposed Change:
> remove entire "and that are created...organization" sentence
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> If this phrase is removed, the definition becomes too inclusive,
> allowing too many things to be considered a set of Web pages.
>
> ----------------------------------------------------------
> Comment 46: supplemental content
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0111.html
> (Issue ID: 2560)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "Example 3: A paragraph describing..."
>
> but the outcomes should already be present in the study....so it's not
> describing, but summarising?
>
> Proposed Change:
> change to "Example 3: A paragraph summarising..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have updated the example as proposed.
>
> ----------------------------------------------------------
> Comment 47: synchronised media - awkward
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0112.html
> (Issue ID: 2561)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "audio o video synchronised with another format..."
>
>
>
> awkward wording
>
> Proposed Change:
> change to "different media elements (audio, video, text\") ..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have revised the definition of captions to address this and other comments.
>
> captions
>
> synchronized visual or text equivalent for both dialog and
> non-dialog audio information needed to understand the media content
>
> Note 1: Captions are similar to dialog-only subtitles except captions
> convey not only the content of spoken dialog, but also equivalents for
> non-dialog audio information needed to understand the program content,
> including sound effects, music, laughter, speaker identification and
> location.
>
> Note 2: Closed Captions are equivalents that can be turned on and off
> with some players.
>
> Note 3: Open Captions are any captions that cannot be turned off. For
> example, if the captions are visual equivalent images of text embedded
> in video.
>
> Note 4: Captions should not obscure or obstruct relevant information
> in the video.
>
> Note 5: In some countries, captions are called subtitles.
>
> Note 6: Audio descriptions can be, but do not need to be, captioned
> since they are descriptions of information that is already presented
> visually.
>
> ----------------------------------------------------------
> Comment 48: viewport - awkward
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0113.html
> (Issue ID: 2562)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "User agent user interface"
>
> Proposed Change:
> change to "A user agent's interface..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We agree, but since this is is based on a term defined elsewhere
> within W3C publications, we have chosen to retain the original
> wording.
>
> ----------------------------------------------------------
> Comment 49: user interface component - missing comma
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0114.html
> (Issue ID: 2563)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
>
> "...programming techniques but ..."
>
> Proposed Change:
> change to "...programming techniques*,* but ..."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Thank you. We have added the missing comma.
>
> ----------------------------------------------------------
> Comment 50: web page example 4
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0115.html
> (Issue ID: 2564)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
>
> example 4 may need clarifying ... this is in effect a single-page website?
>
> Proposed Change:
> specify that ex4 deals with a single-page site
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> This *could* be a one page Web site, but could also be a feature
> within a larger site. In most cases, it would not be a single-page Web
> site. Since making the example be a single page Web site might
> confuse the issue the working group felt it better leave it as it is.
>
> We have added the following to the end of example 4 "This might be a
> single page Web site or just one page within the Web site."
>
--
Patrick H. Lauke
______________________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________
Received on Tuesday, 11 March 2008 01:18:39 UTC