RE: SC classifications

I agree that this is a problem, and, in general terms (with more review needed on my part) support the analysis below.

From: Michael Gower [mailto:michael.gower@ca.ibm.com]
Sent: Thursday, December 7, 2017 11:00 AM
To: WCAG <w3c-wai-gl@w3.org>
Subject: SC classifications

Assuming the Dec 7 version of this https://w3c.github.io/wcag21/guidelines/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__w3c.github.io_wcag21_guidelines_%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DLsubWLi77Ps2I4ozl8IIrEWPNnvGqbYUvZKIHEOX4ls%26s%3Db-6lz_0O5lPdbw98CZy0hFmQTjNq_Ioa64aNh-Oc9Xs%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7C9f6e2f0ba72e48f10b8c08d53d8c2bbc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636482594595341367&sdata=LSIwRb8nsLwwzwUaz9W8gAqjhXOa4ZHVUTxoT%2BRw%2B58%3D&reserved=0> is the correct and most up to date list, I'd like to get some clarity on why things have been classified as they are, and if/when we can address possible changes. To the degree that we can normalize the criteria within the POUR model, we should. (And I get that the model itself does not result in clear delineation.)

Identify Common Purpose - under Perceivable>Adaptable. I get the SC can be theoretically used to do adaptation, but it doesn't really fit with what is covered by the webaim Transformability <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebaim.org%2Farticles%2Fpour%2Fperceivable&data=02%7C01%7Cjjwhite%40ets.org%7C9f6e2f0ba72e48f10b8c08d53d8c2bbc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636482594595341367&sdata=qjxs%2FnuOojGOQra%2BaSTgEjfkhEdpOSjzEo52EJOldx8%3D&reserved=0> topic. Surely its primary purpose is Understandable<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebaim.org%2Farticles%2Fpour%2Funderstandable&data=02%7C01%7Cjjwhite%40ets.org%7C9f6e2f0ba72e48f10b8c08d53d8c2bbc%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636482594595341367&sdata=7pjLhnj2gOwFuBV6HTsM9JWkywQqQMN287CcFBna%2Beo%3D&reserved=0>. Again, realizing this is webaim material not w3c, the topics on meaning seem perfectly aligned. Not a great fit in a subcategory... Readable, isn't horrible. Input Assistance is bang on for the input purposes.

Contextual Information - also under Perceivable>Adaptable. Same argument as Identify Common Purpose. Should be Understandable

Reflow - under Perceivable>Distinguishable. Seems to make more sense under Perceivable>Adaptable. The very title of the SC is something of an argument for this. I understand this is more of a subtle difference, but taking in all the criteria in these two subcategories, it seems to make more sense.

Text spacing - also under Perceivable>Distinguishable. Same argument as Reflow. The SC is about adapting the text. Seems to meet the short description of Adaptable: "presented in different ways (for example simpler layout) without losing information or structure."

Content on Hover of Focus - also under Perceivable>Distinguishable. I get that the goal of this is to ensure everyone can take advantage of the content, but a dispassionate examination of the actual language of the SC suggests that it is dictating Operation. As a double-barrelled SC, it belongs under both Keyboard Accessible and Pointer Accessible. A pragmatic compromise may be to dump it under Navigable with some cross references or something.

Accessible Authentication - under Operable>Enough time.  Definitely agree it belongs under Operable, but since there is no time factor in the SC, it is a loose fit. There isn't really anywhere better. It could be possibly addressed by altering 2.6 from Additional Sensor Inputs to something more generic like Additional Modalities.

Animation from Interactions - under Operable>Enough time. Originally this had some timing factors in it, so was an 'okay' fit. But I think it much more appropriately belongs under Operable>Seizures. I'd also advocate the "Seizures" category be reworded and broadened, but I guess that would be a 2.0 normative change and so is sacrosanct.

Character Key Shortcuts - under Operable>Navigable. I think this fits better under Operable>Keyboard Accessible. Yes, it is there because of voice control, but ultimately it's about an unambiguous keyboard affordance. If people buy into my Operable>Additional Modalities suggestion, it could also fit quite comfortably in there.

Label in Name - under Operable>Navigable. Makes more sense under the proposed Operable>Additional Modalities suggestion. Can actually clarify intent, just by being located there, as otherwise very unclear from from SC language alone what the intent is.

Most Pointer SCs (Gestures, Cancellation, Target Size) - fine as is except...

Concurrent Input Mechanims - under Operable>Pointer Accessible. Since this covers a whole lot more than pointer, it makes a lot more sense under Operable>Additional Modalities.

Status Changes - under Operable>Predictable. I think this actually makes more sense under Perceivable. Subcategory? Probably Distinguishable, or maybe Adaptable.

Cheers,
Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com>
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________