Draft Response issue 736
Thank you for your comment. Specific responses are shown inline below:
2.2.6 Accessible Authentication (A)
This success criterion demands not to rely on "recalling" or "transcribing" when user authentication, and I feel that generally-and-widely used "password authentication" seems to contradict this success criterion.
As an single "A" level criterion, if a website with general "password authentication" does not prevent saving the password to cookie, that website should be judged as meeting this success criterion. Is my understanding correct? (If so, it might be better to represent some guidelines of retention period of cookies.)
The Working Group could not reach consensus on this criterion, so it has been removed from the draft and will be considered in a future version.
1.3.4 Identify Common Purpose (AA)
I interpreted this success criterion that; for each of the controls listed in "7. Common Purposes for User Interface Components", the type of these controls must be made identifiable by the machine. (For example, given the next / previous buttons, having semantics that these buttons are just "button" is not enough, and we should attach the semantics of "previous" button and "next" button.)
If so, it is very difficult to achieve at this time , so I think that it is reasonable to make this success criterion to level "AAA".
Your interpretation is correct. We are modifying this criterion to address only the purposes for inputs, and aligning the list to use the HTML 5.2 autofill list. We are keeping this at AA, but believe that it is much more achievable now.
1.4.10 Reflow (AA)
As for the first "NOTE";
The description of "320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom." seems to be misleading as a note for this success criterion. Because when you zoom a web content originally with 1280 CSS pixels to 400% scale, then the two direction (both vertical and horizontal) scrolling should appears for the 320 CSS pixels-wide viewport.
The working group specified one dimension, but since the goal is to avoid text running off screen in more than one dimension the way that this SC works is that the author needs to make sure that the content can still be used at a screen width of 320 pixels. The height may vary but since the wrapping generally needs to happen horizontally the test in the SC is based on the width. For vertical text we are also clarifying in a note that the width dimension is treated as height since the text is flowing in a different direction.
1.4.11 Graphics Contrast (AA) I'm happy that there is a success criterion for contrast ratios for graphics, in addition to SC 1.4.3 and 1.4.6 (contrast ratios for text). But this new success criterion demands contrast ratio of 3:1, lower than the contrast ratio criterion for text (4.5:1). I think that it is good if the reason of this difference is explicit. In my past website design project, I interpreted that the contrast of icons, buttons etc should also conform to SC 1.4.3, and tried hard to keep the ratio of 4.5:1.
3:1 is the ratio because there are many more possible combinations of adjacent colors than are typically found in text. We have received many comments to this effect and made the ratio 3:1 in response to public and working group input.
1.4.12 Text Spacing (AA) "Word spacing" is included in the list. I understand the importance of this list item, but for languages which don't have spacing between words (such as Japanese), this item should be exempted. In the case of Japanese language, if you put a space between words, "particles" and "auxiliary verbs" are separated, making it cognitively difficult to read.
We are aware of this issue and will be creating an exception to address this.
1.4.13 Content on Hover or Focus (AA)
As for "Dismissable"; I don't have confidence that I understand this item correctly, but does this mean interactions such as pressing Esc key to close "additional content" ?
As for "Hoverable"; I interpreted that this item is for solving problems as described in http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown , to prevent "additional content" from closing unexpectedly to the user. If so, I think it is preferable to have a description like "Even if the user takes shortcut pointer movement (in a way that the original hover focus drops off)".
As for "Persistent";
This item seems to allow "additional content" closing as soon as the hover is removed, and I feel it misleading because this doesn't solve problems as described in http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown (unpleasant behavior for users as shown in the 3rd GIF animation).
re: dismissible - your interpretation is correct.
re: hoverable - We understand the issue, but cannot identify clear language to address this in a way that is testable. This issue does also affect all users, so it may be that it is a general usability issue that WCAG wouldn't cover. We will mark this issue as "defer" for future consideration.
re: persistent - This seems to be the same issue mentioned above as "hoverable".
2.5.3 Target Size (AA)
This success criterion says that one side can be 22 CSS pixels. But if there are some "44 px-wide and 22px-high" touch objects and being stacked vertically with no margins, it is likely to cause incorrect taps.
Because this success criterion already has excemption note of "Inline", I think that the minimum size of the touch target can be set as 44 x 44 CSS pixles.
It is worth noting that the Apple and Google guidelines do not include text links, and that is a large part of the challenge in this SC. We understand your interest in a 44x44 size, and this and related questions have made it difficult for the WG to reach consensus on the language for 2.5.3, so the SC has been removed from the latest draft.