- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 22:05:43 -0700
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: public-comments-WCAG20@w3.org
Comment 25: Awkward non-word "turnon" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0351.html (Issue ID: 2206) ---------------------------- Original Comment: ---------------------------- "Audio Turnon" Turnon? Making audio "on/off-able"? Proposed Change: "Audio Control" --------------------------------------------- Response from Working Group: --------------------------------------------- Very good suggestion. We have updated the text as proposed. Thank you. ---------------------------------------------------------- Comment 26: resized without AT Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0352html (Issue ID: 2207) ---------------------------- Original Comment: ---------------------------- "Visually rendered text can be resized without assistive technology..." This is still dependent on a user agent that follows UAAG recommendations, though. Also, "without assistive technology\" may sound awkward, when you mean "in common user agents" or similar...admittedly a tricky one. Proposed Change: "Visually rendered text can be resized in UAAG compliant user agents, without the use of any additional magnification software, ..." --------------------------------------------- Response from Working Group: --------------------------------------------- The techniques used to satisfy this success criterion must be accessibility supported, as described in the Conformance section. If non-UAAG compliant user agents are those that are available to users, the author must still see that this success criterion is satisfied. Changing the success criterion to depend upon UAAG compliant user agents would weaken it substantially. We looked at your suggestion to use "additional magnification software" but found that using "assistive technology" addressed more clearly issues of where the magnification was implemented. That the assistive technology is a screen magnifier is explained in the Understanding WCAG document. ---------------------------------------------------------- Comment 27: 2.1.1. trying to cover two separate issues in one go? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0354.html (Issue ID: 2208) ---------------------------- Original Comment: ---------------------------- "All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints." To me, these feel like two separate issues (operability and timing) mashed into one. Would it be useful to split these (which admittedly would need renumbering of the remaining 2.1 SCs)? Proposed Change: "2.1.1 All functionality of the content is operable through a keyboard interface, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. 2.1.2 Keyboard operation does not require specific timings for individual keystrokes 2.1.3 ..." --------------------------------------------- Response from Working Group: --------------------------------------------- This provision is to ensure that functionality can be controlled with individual keystrokes. The timing clause is critical to this provision to ensure that the keystrokes are discrete events and not timed. For example a person using sip-and-puff Morse code can type letter but not hold them down for varying lengths of time. Separating the clause into two would work but would also prohibit any use of the keyboard in a timed fashion. That is more than what is required. It is ok to use the keyboard in that fashion as long as it is ALSO possible to achieve the function on the keyboard without timing. Thus the current coupling of the two aspects is correct. ---------------------------------------------------------- Comment 28: just "users with disabilities"? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0355.html (Issue ID: 2209) ---------------------------- Original Comment: ---------------------------- "Provide users with disabilities enough time..." Surely ALL users, not just those with disabilities. Proposed Change: "Provide users enough time..." --------------------------------------------- Response from Working Group: --------------------------------------------- Because WCAG addresses the particular needs of users with disabilities, we feel it is important to mention them explicitly. Users with disabilities often need more time than other users, so we trust that if they have enough time, so will users without disabilities. ---------------------------------------------------------- Comment 29: in practice, difference between "blink" and "flash" still unclear, even with appendix Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0356.html (Issue ID: 2210) ---------------------------- Original Comment: ---------------------------- It's unclear here what the difference between blink and flash actually is, in practice. Looking at the appendix, there's a definition for "blink", but strangely not for "flash". The note in the appendix definition of "blink" still leaves me wondering: "The slower blink is in contrast with flashing, which refers to rapid changes in brightness..." If blinking is a complete on/off, is it not simply a special case of flashing? Proposed Change: Just stick with flashing or blinking throughout the document, as it's confusing (and in practice, completely irrelevant I'd argue) to distinguish between a blink and a flash. --------------------------------------------- Response from Working Group: --------------------------------------------- We have added a definition for flash and clarified the difference between flash and blink both in the definitions and (in longer form) in the understanding document --- flash: a pair of opposing changes in relative luminance of 10% or more where the relative luminance of the darker image is below 0.80 Note: Flash is characterized by rapid changes of relative luminance occurring more than three times per second, while [blink] is less than three times per second. Note: See [general flash threshold] and [red flash threshold] for more precise information about the applicability and constraints of flash. --- blink: switch back and forth between two visual states in a way that that does not qualify as [flash] (e.g. it is too slow and/or the change in relative luminance is too small to qualify as flashing) Note: The slower blink is in contrast with [flash], which refers to rapid changes in brightness which can cause seizures. See [general flash] and [red flash] thresholds. --- Added to understanding documents: NOTE: In some cases, what we refer to as "blinking" and what we refer to as "flashing" may overlap slightly. We are using different terms for the two because one causes a distraction problem which you can allow for a short time as long as it stops (or can be stopped) whereas the other is a seizure trigger and cannot be allowed or it will cause a seizure. The seizure would occur faster than most users could turn it off. "Blink" therefore refers to slow repeating changes that would distract. Flash refers to changes that could cause a seizure if they were bright enough or persisted long enough. Blinking usually doesn't occur at speeds of 3 per second or more so blink and flash do not overlap. However, blinking can occur faster than 3 per second so there could be an overlap. ---------------------------------------------------------- Comment 30: the SC should be applicable even on a single page Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0357.html (Issue ID: 2211) ---------------------------- Original Comment: ---------------------------- "A mechanism is available to bypass blocks of content that are repeated on multiple Web pages." This should be just as applicable to content that's just on one page, surely? Yes, we're thinking navigation and "skip to content" here, but it's just as important to ensure that content itself, even if on only one page, is properly structured etc to allow for structured navigation. Proposed Change: "A mechanism is available to bypass blocks of content, particularly if these blocks are repeated on multiple Web pages" --------------------------------------------- Response from Working Group: --------------------------------------------- You make a good point, we strongly promote structural markup. We require that information and relationships conveyed through presentation are also available programatically (1.3.1), which is a level A requirement. The expectation is that over time, this provision will enable user agents and assistive technology to rely on grouping and structure to navigate around a page more efficiently. This is why the provision is worded as "a mechanism is available". If the document structure provided allows user agents to support skipping the content, then a mechanism is available and this success criterion is satisfied. This provision is designed to free users of repeatedly navigating the same menu structures from page to page, and which they have already understood. However, within a single page, content that is not repeated on multiple pages will likely be new to the user. SC 1.3.1 discusses the importance of structural markup which facilitates effective navigation. We have added a note to 2.4.1 "Note: Although this success criteria deals with blocks of content that are repeated on multiple pages, we also strongly promote structural markup on individual pages as per Success Criteria 1.3.1." ---------------------------------------------------------- Comment 31: just "users with disabilities"? (GL 2.4) Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0358.html (Issue ID: 2212) ---------------------------- Original Comment: ---------------------------- "...to help users with disabilities navigate..." surely ALL users. Proposed Change: "...to help users navigate..." --------------------------------------------- Response from Working Group: --------------------------------------------- Because WCAG addresses the particular needs of users with disabilities, we feel it is important to mention them explicitly here. Users with disabilities often need more or different help with navigating, finding content, and orienting themselves than other users, so we highlight addressing their needs. ---------------------------------------------------------- Comment 32: whole SC seems unnecessary Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0359.html (Issue ID: 2213) ---------------------------- Original Comment: ---------------------------- I'd contend that the whole SC falls under the realm of usability. There are many situations in which this SC, under the lax definition of "set of Web pages", would be considered applicable but shouldn't. What about a small site for a design freelancer with "who i am / see my work / hire me" sections. These have a "specific relationship" to each other. So, does the site need both a navigation and a search function, for instance? Or a table of contents? Proposed Change: Drop the SC altogether, or seriously tighten the definition of "set of Web pages". --------------------------------------------- Response from Working Group: --------------------------------------------- We have narrowed the definition of "set of web pages" as follows set of Web pages collection of Web pages that share a common purpose and that are created by the same author, group or organization. Note: Different language versions would be different sets of Web pages. ---------------------------------------------------------- Comment 33: mechanism, or should it be "programmatically determined", or both? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0360.html (Issue ID: 2214) ---------------------------- Original Comment: ---------------------------- "A mechanism for finding the expanded form or meaning of abbreviations is available" Should it be a mechanism, or a mechanism and/or programmatically determined, or just programmatically determined? Probably the second option (so it could cover both the use of ABBR with relevant TITLE attribute and the possibility of a separate glossary page). Proposed Change: "A mechanism for finding the expanded form or meaning of abbreviations is available, or the expanded form can be programmatically determined." --------------------------------------------- Response from Working Group: --------------------------------------------- Programmatically determined expanded forms are already sufficient to meet this success criterion. However, there are other mechanisms which are also sufficient, such as adding a glossary. While the working group has provided both types of techniques, we feel that adding the "programmatically determined" to the success criterion would make it unnecessarily difficult to read. ---------------------------------------------------------- Comment 34: reclassing 3.2.5 from AAA to A Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0361.html (Issue ID: 2215) ---------------------------- Original Comment: ---------------------------- "Changes of context are initiated only by user request. (Level AAA)" As changes in context (auto-loading a new page, moving focus, etc) can be problematic for many users (those using AT, those with cognitive disabilities, etc), I'd posit that this should be reclassed to A, not AAA. Proposed Change: Change from AAA to A, or at the very least AA. --------------------------------------------- Response from Working Group: --------------------------------------------- SC 3.2.5 is a Level AAA success criterion because there are some web sites that provide functionality that is not possible if changes of context are only initiated by user request. Examples are activities with realtime properties, time-out warnings, and emergency notifications. SC 3.2.1 and SC 3.2.2 are Level A success criteria that prevent the most common types of changes in context that cause problems for users - changes in context when a component receives focus, and changes in context without warning when a setting has changed. SC 2.2.1 is a Level A success criterion that requires that users be given control over actions like auto-loading new pages. This particular issue is called out in Failure F58 - Failure of SC 2.2.1 due to using server-side techniques to automatically redirect pages after a time-out. ---------------------------------------------------------- Comment 35: just "in text"? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0362.html (Issue ID: 2216) ---------------------------- Original Comment: ---------------------------- "...described to the user in text." Why "in text"? Provided that the description also follows the relevant other WCAG 2 guidelines, the error description could be an image, or use of colour, or anything else for that matter. Proposed Change: ""...described to the user." --------------------------------------------- Response from Working Group: --------------------------------------------- The requirement of text is not exclusive. Images, color etc can be used also. The working group feels that it is helpful that the sentence includes the words "in text" even though technically this is required by SC 1.1.1. Our goal is to make the Success Criterion as understandable as possible, and we feel this improves the clarity of what is required. We have added to the understanding section the following: "It is perfectly acceptable to indicate the error in other ways such as image, color etc, in addition to the text description." ---------------------------------------------------------- Comment 36: bullet 2, "checked", seems unnecessary Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0363.html (Issue ID: 2217) ---------------------------- Original Comment: ---------------------------- "Checked: Submitted data is checked for input errors before going on to the next step in the process." The concept of checking for errors sounds to me like a common application design tenet, not an accessibility one. Also, why should the app check for errors before moving on to the next step? Would a final screen saying "there were errors in steps 3 and 5, here are the fields for you to edit" or similar not work as well? Proposed Change: Bullet 2 seems unnecessary, or requires better wording. --------------------------------------------- Response from Working Group: --------------------------------------------- Although this is a common application design tenet, this success criterion addresses a problem that affects some users with cognitive or learning disabilities disproportionately. We changed the wording of this option to make it clear that feedback on input errors should be given as soon as possible, but it is not required to give such feedback instantly. Some processes wait until all the input has been gathered and check for errors just before submitting. We changed the wording of this option to make it clear that users should be given feedback on input errors as soon as possible: ---------------------------------------------------------- Comment 37: Awkward and incomplete wording Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0364.html (Issue ID: 2218) ---------------------------- Original Comment: ---------------------------- It's understandable that, by not wanting to mandate "validates", the wording became awkward. "...has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications." It's also, in its current form, very much HTML/XML specific. Also, it doesn't really drive home the idea of "semantic/structural" markup, when this would be a great place to put it in, potentially? Proposed Change: A more tech-agnostic and elegant way: --------------------------------------------- Response from Working Group: --------------------------------------------- The working group struggled for a long time, trying to write a tech-agnostic, elegant success criterion. Ultimately, the group determined that in fact the accessibility concerns of validity are specific to markup languages. This wording emerged because: - in stricter technologies, such as XML-based technologies, well formedness problems affect everyone, so they are not an accessibility issue - many validity problems cause failures that are already covered by other success criteria - the problems with determining structure due to parsing problems in markup languages cause accessibility problems, since they interfere with assistive technology in a way that they do not interfere with host user agent For these reasons, the Working Group believes this success criterion is worded as clearly and accurately as is possible for the situation. ---------------------------------------------------------- Comment 38: Addition to "Creating your own list..." section. Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0365.html (Issue ID: 2219) ---------------------------- Original Comment: ---------------------------- Current wording of the "Creating your own list..." bit could be misread to mean authors etc can just make them up as out of thin air. May need clarification. "Authors, ... accessibility-supported technologies." Proposed Change: "Authors, ... accessibility-supported technologies, based on the rules outlined in the following section." --------------------------------------------- Response from Working Group: --------------------------------------------- We have added the following "However, all technologies on the list must meet the definition of accessibility supported content technologies above." to the definition of accessibility supported.
Received on Sunday, 4 November 2007 05:05:56 UTC