Sun Review of WCAG 2.0

Dear WCAG;

Thank you for the opportunity to review this draft and for the
hard work that's been put into it. The following is Sun's
feedback on the WCAG 2.0 working draft [WD-WCAG20-20040311].

On behalf of Sun,

Earl Johnson
Sun Microsystems

{\rtf1\ansi\ansicpg1252\deff0\deftab709{\fonttbl{\f0\fnil\fcharset0 Courier New;}{\f1\fmodern\fprq1\fcharset0 Courier New;}{\f2\fmodern\fprq1 Courier New;}{\f3\fnil\fcharset2 StarSymbol;}}
{\*\generator Msftedit 5.41.15.1503;}\viewkind4\uc1\pard\lang1033\f0\fs20 Dear WCAG;\par
\par
Thank you for the opportunity to review this draft and for the hard work that's been put into it. The following is Sun's feedback on the WCAG 2.0 working draft [WD-WCAG20-20040311].\par
\par
On behalf of Sun,\par
\par
Earl Johnson\par
Sun Microsystems\par
\par
---------------------\par
\par
\tab Sun Microsystems' Feedback on WCAG 2.0 Working Draft\par
\par
Contact:\par
\tab Earl Johnson\par
\tab 06/14/04\par
\par
General Question About Focus\par
\pard\li283 1.  When a page refreshes the UA places focus at the top of the page. This is fine when the user is changing the URL but sometimes the user is simply requesting an update to what is in their page. A Calendar application is one example - it comes up with the current month and highlights the current day, has fields for making or changing appointments, and makes it possible to find out more information on a particular appointment. \par
\par
In some web applications, if the user changes the month, the resulting update triggers a refresh. In this case, you don't want the focus placed at the beginning of the page so the user must navigate back to their initial point of focus, you want focus position to be maintained. But maintaining the users focus following this won't consistently happen until:\par
\pard\li992 a] The UA is able to retain the focus and scroll location through a refresh when instructed to [unless this is already supported]\par
b] The WCAG provides guidance on what the content needs to do to ensure it tells the browser to save then restore focus to the saved position [is cookies the best way to do this?]\par
c] The WCAG provides a focus oriented success criteria saying something like "focus and scroll location must be maintained when a URL is updated not changed [i.e. when content goes through a minor context change occurs]"\par
\pard\par
\pard\li283 But then again, is this an appropriate topic for the W3C/WAI/WCAG to tackle? If focus manageability is something worth supporting, should WCAG 2.0 cover it?\par
\pard\par
From the Introduction:\par
\pard\fi-283\li283\f1   \f2 1. \f1  \f2 C\f0 onformance: The second Editorial Note descriptions of [I] and [V] following each Success Criteria are confusing. It's almost like they say - [I], invisible, applies to efforts whose results you'll see; and [V], visible, applies to efforts whose results you won't see. This feels backwards.\fs24\par
\fs20\par
  If this interpretation is correct, it would seem more appropriate to tie the effect the developer's efforts have on what the user sees [in the literal sense] to the [V] and vice-versa for the [I]. For example, something essentially saying: "[V], the work you've done is visible to the user; and [I], the work you've done is invisible to the user." This will also, hopefully, make it easier to remember what they mean in later SC.\par
\par
  Or maybe there was a mix-up in the Note? For example, the Level 2 Success Criteria for Guideline 1.4 will contain specific contrast value that must be met. This specifies how something looks so would by definition be an [I]; but the guideline has a [V]... Confusing.\par
\par
  Or perhaps the meaning or benefit of what is being conveyed to the reader in this, or any different, special symbol needs to be re-visited? \par
\pard\li283\par
2.  Overview of Design Principles: This sub-section introduces the curb cut factor. By contrast, all of the examples provided in the guidelines appear to focus on the benefits someone with a disability gains when the content provider meets a particular guideline. Would it help readers who didn't read this section if examples of ways people "without disabilities" benefited from the content provider's efforts were lightly sprinkled in these guidelines?\par
\pard\par
\pard\li283 3.  General: \par
\pard\li992 a.  It would really help if one can know if a criterion is testable automatically, manually, or not at all.\par
b.  Isn't "Content must be testable" another goal of these guidelines?\par
\pard\par
\par
Guideline 1.1: \par
\pard\li283 1.  Level 1 Success Criteria 2: Early on in their accessibility efforts, some of our content providers felt that WCAG was saying every image needed a LONGDESC ["text description"]. Instead, we feel the use of text descriptions is conditional - provide them only when the text equivalent and/or text label aren't sufficient. It may be helpful to have the definition of "text description" or "text equivalent" include guidance on when it is appropriate being set.\par
\pard\par
Guideline 1.4\par
\pard\li283 1.  Level 3 Success Criteria 1: This Success Criteria says it only covers default backgrounds while Level 2 Success Criteria1 covers backgrounds in general. Level 3 Success Criteria 1's coverage is narrower than Level 2 Success Criteria 3's. If this is the case, these criteria should be swapped.\par
\pard\par
Guideline 1.5\par
\pard\li283 1.  It is odd having an Level 2 guideline with no Level 2 Success Criteria. What is the reasoning for not make this a Level 3 guideline or change the Level 3 Success Criteria to Level 2 Success Criteria?\par
\pard\par
Guideline 2.1\par
\pard\li283 1.  General: It's not clear what the difference is between the Level 1 and Level 3 Success Criteria 1.\par
\pard\li992 a.  Does Example 1 demonstrate how Level 3 criteria is met and Example 2 demonstrate how Level 3 criteria is met? \par
b.  It would be very helpful if every Example in each Guideline identified which Success Criteria it was meeting.\par
\pard\par
\pard\li283 2.  Example 2 - A keypad is a type of keyboard; you can use the keypad on a cell phone, for example, to type messages to your friends using the keypad. A Blackberry, among other products, even provides its own mini keyboard. Example 2 suggests the keyboards on these devices don't meet this Guideline's requirement. It's not clear anywhere in this document why this is the case. Perhaps a definition of keyboard should be add to make clear what is and isn't considered to be a keyboard.\par
\pard\par
Guideline 2.3\par
\pard\li283 1.  Combining the General and Red Flash Threshold guidance with the Level 3 Success Criteria is confusing.\par
\par
2.  Editorial Note: does "free tool" mean it will be free to any vendor who wants to include it in a product they sell?\par
\pard\par
Guideline 2.4\par
\pard\li283 1.  Level 2 Success Criteria 3: This Success Criteria is similar to 1194.22[o], [see below]. Our understanding was WCAG 2.0 was, in part, an attempt to "harmonize" with 508. This perspective suggests then that anything in 1194.22 ought to be considered a Level 1 Success Criteria. We recommend this and all other 1194.22-like Success Criteria in these guidelines be made Level 1 Success Criteria.\par
\pard\par
\tab 1194.22(o) A method shall be provided that permits users to skip repetitive navigation links.\par
\par
\pard\li283 2.  Level 3 Success Criteria 3: Defining what logical tab order means would, at a minimum, help testers know what a logical tab order is. Having this knowledge could have the added benefit of making this Success Criteria [at least a little] more testable than it currently is.\par
\pard\par
Guideline 2.5\par
\pard\li283 1.  Level 2 Success Criteria 1: This is a pretty important requirement for form entry validation at a minimum. Upgrading it and this guideline to Level 1 seems appropriate. Since it's mentioned, our presumption is security concerns are why this is an Level 2 Success Criteria and the guideline is also Level 2 instead.\par
\pard\li992 a.  Why isn't this Success Criteria and guideline considered Level 2?\par
b.  If security is the reason, is there a path with through the stated concerns that might make a more prescriptive Level 1 Success Criteria acceptable?\par
\pard\par
\pard\li283 2.  Level 3 Success Criteria 1: Giving the user choice over input options makes sense but this portion of the guideline doesn't "Where the input options are known, there are less than 75 of them, and". \par
\pard\li992 a.  What does the statement "there are less than 75 of them" mean?\par
b.  If it means something like "there are currently 75 known input ways/modes a user can interact with content": Should they be enumerated and pointed to from the WCAG?\par
\pard\par
Guideline 3.1\par
\pard\li283 1.  General: This guideline includes a discussion about locating and determining acronyms, abbreviations, and idioms. From a visual perspective, should they look different from each other and URL type jump links? The guidelines are neutral on this point, should they remain this way?\par
\par
2.  Level 3 Success Criteria: The Editorial Note warns more Success Criteria will be added to this Level if a method for making the items under the Note testable. This suggests the WCAG will use different metrics for determining if something is testable than those used for the other Success Criteria within these guidelines. \par
\pard\li992 a.  What metric[s] will be used to determine an item on the list is testable?\par
b.  More generally, has the WCAG identified which Success Criteria are machine testable? human testable? is this partly what the [I] and [V] definitions and symbols are meant to do?\par
\pard\li1701 1]  If it isn't already identified on the Success Criteria should it be or is it considered a moving target [i.e. what isn't machine testable now may be in the future]?     \par
2]  Has the WCAG already generated a list that says why and how they think a given Success Criteria is human or machine testable?\par
3]  This seems different than techniques\par
4]  This may assist the internal test developer by allowing them to quickly determine where the shortcomings in commercial tools might be so they can ask more informed questions of vendors web content accessibility checking tools when they're considering a purchase.\par
\pard\par
Guideline 3.2\par
\pard\li283 1.  General Editorial Note: "View" is a possibility. One of http://www.m-w.com's noun definitions of View says it is "a mode or manner of looking at or regarding something ..." People use their eyes, ears, hands, and, at times, nose and mouth as the "manner" in which they regard the web pages, movies, or music they've asked for.\par
\par
2.  Level 2 Success Criteria Editorial Note: they may be more subtle than, say, spawning a new wind ow/browser but extreme changes of context can happen within non-HTML content also can't they?\par
\pard\par
Guideline 4.1\par
\pard\li283 1.  Example 3: The IBM guidelines have the following attributes: \par
\pard\li992 a.  They talk about the Java Accessibility API and how to build accessible custom UI components;\par
b.  Their primary focus is heavy duty Java developers developers\par
\pard\par
\pard\li283 These are fine attributes if the expected audience for WCAG are developers. But the audience for these guidelines will be quite varied - e.g. developers, designers, testers, and "compliance" checkers. Given the broad readership of the WCAG, we suggest that the links provided in WCAG examples should be to sites that contain information relevant to a variety of readers since these guidelines are meant to be instructive to readers from various disciplines. With this in mind, we suggest changing the link in this example to the following [which also includes IBM's guidelines]:\par
\pard\tab http://www.sun.com/access/developers/index.html\par
\par
Guideline 4.2\par
\pard\li283 1.  The plugin for JavaScript is the browser and the technology it interacts with includes the DOM, CSS, and HTML. To our knowledge, these technologies do not possible for the content provider to do things like JavaScript menus and other more complex UI objects in a way that meets many of the guidelines and Success Criteria in WCAG 2.0 and the UAAG. These guidelines shouldn't preclude the use of JavaScript but, due to the lack of support in various W3C defined technologies [1], they do. This appears to be an issue the W3C [versus private vendor] needs to drive. What is the WCAG's thinking on how to deal with this issue? \par
\par
Being able to use JavaScript and also meet WCAG's guidelines are important requirements for many content providers, especially in the web applications space. Shouldn't the release of these guidelines be delayed until an achievable path that enables content providers has been agreed upon and is in the works?\par
\pard\par
Notes:\par
[1]  http://www.w3.org/WAI/PF/Group/roadmap/\par
\par
---------------\par
\par
\tab Input on the Testability of Each Success Criteria\par
\par
The following is the set of Success Criteria we feel require human intervention or special tools in order to fully determine if the content the criteria. Those that aren't on this list are felt to be able to be determined via automated testing [though this should be validated].\par
\par
 \par
Guideline 1.1 Level 1 Success Criteria:\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Semi-automatically testable. i.e., it's possible to automatically test that text equivalents are available, but need manual intervention to test if such equivalents *work*. \par
\pard\par
Guideline 1.2 Success Criteria:\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Manually testable. \par
\pard\par
Guideline 1.3 Level 1 Success Criteria 2 and Level 2 Success Criteria 1:\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Manually testable. \par
\pard\par
Guideline 1.4\par
Level 2&3 Success Criteria:\par
\pard\fi-283\li992\f3\fs18 "  \f0\fs20 NOT testable unless appropriate tools are available.\par
\pard Level 3 Success Criteria 2:\par
\pard\fi-283\li992\f3\fs18 "  \f0\fs20 Manually testable. \par
\pard\par
Guideline 1.5 Level 3 Success Criteria 1:\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Hard to test without specialized tools. Including examples of acceptable/unacceptable/borderline cases might help testers make an educated guess in certain cases.\par
\pard\par
Guideline 2.1 Level 2 Success Criteria 1:\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Manually or automatically testable: depends on context.\par
\pard\par
Guideline 2.2\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Manually testable.\par
\pard\par
Guideline 2.3\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Automatically testable with Trace Center tool.\par
\pard\par
Guideline 2.4\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Manually testable.\par
\pard\par
Guideline 2.5\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Manually testable\par
\pard\li992 Defining standard markup or attribute[s] for identifying when something is corrective would help "move" much of the testing for this  guideline into the automatically testable category.\par
\pard\par
Guideline 3.2\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Semi-automatically testable. Scripts can make a tester's life easier.\par
\pard\par
Guideline 4.1\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Might require manual testing, but should be pretty easy to test.\par
\pard\par
Guideline 4.2\par
\pard\fi-283\li283\f3\fs18 "  \f0\fs20 Depending on the technology used, this should be pretty straightforward to test.\par
\pard\par
\par
\par
\par
}