Commenter: Al Gilman
Email: Alfred.S.Gilman@IEEE.org
Affiliation:
Date: 19 May 2006
Please ensure that the comments submitted are as complete and "resolvable" as possible. Thank you.
1. |
2. |
3. Part of Item (Heading) |
4. Comment Type (G/T/E/Q) |
5. Comment (Including rationale for any proposed change) |
6. Proposed Change (Be specific) |
|---|---|---|---|---|---|
| W2 | 2.4.5 | term: descriptive | T/E | Having the HTML spec say that @alt was to contain a short description of the image caused years of dysfunctional ALT texts to be written. Haven't we had enough of this? "Descriptive" is narrow in a misleading way; need something that is more evocative of the breadth of information covered by these various compoents and their short labels. | Use "are explanatory" or "are fitting." |
| W2 | 3.1.3, 3.1.6 | redundant | T | If there is a mechanism that satisfies one of these, there is a mechanism that satisfies the other, because the UA can infer meaning from pronunciation and vice versa. | merge these two clauses |
| W2 | 2.3 | wrong principle | G/T | Principle is "First, Do no Harm." Compare with Hippocratic Oath. This is a safety requirement, it comes before access requirements, and is not an access requirement. |
Introduce separate principle for safety and move this guideline to it. Make it the first, before others. Remove all obstacles to implementing this provision severable from the rest. |
| W2 | 2.4.6 | whole | G/T | Navigation is a User Agent function enabled by structure in the content. This is not a content guideline, but a user experience requirement handled in the User Agent. | Replace with a narrower provision that says "navigation paths defined in the content encoding correspond to the logical order information which is the subject of 1.3.3" |
| W2 | 2.4.8 | whole | G/T | On the face of this, the requirement is unenforceably vague. Need to spell out what you mean by "the purpose of the link" and limit the requirement to concepts the user is likely to recognize. | Re-state as (roughly) "When the result of activating a link falls within the general meaning of a widely used and understood term or notion such as 'help' or 'home,' and there is a widely-reognized name or URI for this concept, the association of this link with that concept is machine-recoverable from the encoding of the content (Note 'encoding'). |
| W2 | 2.5.1 | entire | G/T | This is a general usability practice. | Reorganize to adress overlap with general usability in a positive way. See other comments on organization and explanation. |
| W2 | 2.5.1 | "error is identified" | T | unenforceably vague | "item which system feels to be in error is identified." |
| W2 | 2.5.1 | "in text" + level | G/T | Identifying
the bad entry is enough so long as the entry is prompted/labeled
adequately. In other words affordance of help recovering from
data entry errors is good advice, but too demanding at a Level 1
success criterion standard. Also, authors just get this wrong too easily. How many times does the text explanation say "bad password" when the error was in the username? Error explantions should follow the culture of the desktop. If there is a screen reader in use, this is the screen reader's habits for expressing error messages. The content should define the error as formally as they can. Let the UA and AT worry the friendly message. If the UA knows it is a type error and the type is identified, then that is enough to synthesize an error explanation in diction the user will understand in the culture of their desktop formed by their AT. System codes would not make that error. The point is that the server refused the authentication information pair of username *and* password. | Separate identification of the bad data from explanation of how it is bad. Move explanation of nature of error to lower level. Allow satisfaction by either text message or metadata understandable by user's automation. |
| W2 | 3.2.1 | language | G/T | Navigating to another frame or page is "when an element receives focus" and is at the same time a change of context. There is an anticipated change of context in navigation acts which cause an element to receive focus. [AT can track the focus.] What you want to eliminate is surprises -- context changes that could not be predicted from the prior context in which the focus change was precipitated. So you need language that distinguishes the surprises to be avoided from the context changes that the user will anticipate. | Re-state as (roughly) "When and element receives focus, it does not have any side effects in the form of a further change of context. " |
| W2 | 3.2.4 glossary | "same functionality" "identified consistently" | T | The
definition in the Glossary makes the similarity test for things that
are to be identified alike too narrow. It says identical result;
that is much too narrow. This equivalence class should be made as
broad as possible until it starts to degrade the user's ability to
predict the system response from the prompt material. For
example, context-sensitive help will be identified in the context menu
simply as 'help' although the precise results are different for each
context. This minimizes the vocabulary the user has to learn. The
class of like-identified action opportunities defines the actual
concept; the question is how the user's interpretation of the prompt
material -- the concept identification -- matches this. | Move to section under the education and usability principle "repetition builds recall" In other words, address usability explicitly in the development of the set of provisons, don't just make a vague disclaimer that doesn't admit how what we do say is straight from usability, but applied to mitigating PWD risks of funtion failure, task failure or interminable task times. |
| W2 | 3.2.4 | "a set of web units" | T | Without some restriction on what set is meant, this success criterion is meaningless. But for what you want to say, it can be fixed. | "the Web units comprising the scope of a conformance claim" |
| W2 | 3.2.4 | G | This is a general usability matter; while doing well on this helps PWD, it is not clear that it meets your claimed requirement for inclusion that there be a markedly disproportionate effect on the experience of the PWD user. | Re-state filter criterion for practices in terms of "do cover usability enhancements that are readily achievable and make major contributions to mitigating PWD hazards in the browse experience. But generally good usability practices that have a generally comparable benefit for PWD and TAB users are not covered here." I.e. lead with positive because navigation, view controls, and labeling/prompting are general usability strategies and are of the essence in securing a Web that works for PWD. |
|
| W2 | |||||
| W2 |