Addressing weak SC Classifications

[mbgower]

I sent the below material out last year. Given the discussion on 1.3.4 and 3.2.6 -- and the clear inference that changes in classification are allowed at this stage in the process -- I want to submit a review of all the SCs listed here as an issue for consideration. I have not altered my original material, other than updating changes to the SC language since the December draft (which I've noted in square brackets).

Identify Common Purpose [Same name but language only covers inputs now] - 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 topic. Surely its primary purpose is Understandable. 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.

Identify Purpose [previously 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 [no longer in the CR] - 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 the language had some timing factors in it, so was an 'okay' fit. But there is no time consideration now. 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 Mechanisms - 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.

[awkawk]

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

[mbgower]

After more consideration, I would also like to advocate altering the 3.1 Readable guideline under the Understandable principle to become 3.1 Meaningful. All the existing items in it still fit with that editorial change -- in fact "meaning" is called out in many of them and most are made more precise and understandable with that word change, and none are reduced.

• Language of Page [i.e., making text meaningful by designating its language]
• Language of Parts [designate except where its meaning is clear in the "vernacular" of the default page language]
• Unusual Words ["definitions of words or phrases used in an unusual or restricted way" AKA meaning]
• Abbreviations ["meaning of abbreviations is available"]
• Reading Level [making it meaningful to lower secondary education level]
• Pronunciation ["...where meaning of the words, in context, is ambiguous without knowing the pronunciation"]

With that word change in effect, both 1.3.4 and 1.3.5 can be moved under the Understandable principle where they more naturally fit; 1.3.4 can be moved to the precise Input Assistance with 1.3.5 fitting underneath the more general Meaningful. That allows them to remain under the same Principle, which addresses many of the concerns expressed about moving only 1.3.4

[johnfoliot]

both 1.3.4 and 1.3.5 can be moved under the Understandable principle where they more naturally fit

That opinion is not universally shared in this WG Mike, sorry. (In fact, it appears from Tuesday's call that it is but the minority dissenting opinion). I for one strongly disagree with your assertion. Please feel free to respond to the ongoing CfC about moving 1.3.4 https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/1479.html

JF

On Thu, Mar 15, 2018 at 12:37 PM, Mike Gower notifications@github.com wrote:

After more consideration, I would also like to advocate altering the 3.1 Readable guideline under the Understandable principle to become 3.1 Meaningful. All the existing items in it still fit with that editorial change -- in fact "meaning" is called out in many of them and most are made more precise and understandable with that word change, and none are reduced.

• Language of Page [i.e., making text meaningful by designating its language]
• Language of Parts [designate except where its meaning is clear in the "vernacular" of the default page language]
• Unusual Words ["definitions of words or phrases used in an unusual or restricted way" AKA meaning]
• Abbreviations ["meaning of abbreviations is available"]
• Reading Level [making it meaningful to lower secondary education level]
• Pronunciation ["...where meaning of the words, in context, is ambiguous without knowing the pronunciation"]

With that word change in effect, both 1.3.4 and 1.3.5 can be moved under the Understandable principle where they more naturally fit; 1.3.4 can be moved to the precise Input Assistance with 1.3.5 fitting underneath the more general Meaningful. That allows them to remain under the same Principle, which addresses many of the concerns expressed about moving only 1.3.4

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-373461750, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c1tkLx6c6cvvQagJT-SmTxgwwO9Dks5teqbbgaJpZM4SsQFH .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

Please feel free to respond to the ongoing CfC about moving 1.3.4

Thanks, I did. But how can "Common Purpose" and things to do with meaning not more logically fall under the Understandable principle as opposed to the Perceivable principle?

Principle 3: Understandable - Information and the operation of user interface must be understandable.

Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

I regard to your comment on it being a "minority dissenting opinion", what we were asked was who could not live with it "here" or "there". A few people couldn't live with it one way or the other, nothing like the majority. For the majority of us who didn't feel that strongly either way, we were never asked to indicate our preference.

[johnfoliot]

As Glenda previously noted:

1. WCAG 2.0 Guideline 1.3 Adaptable - Guideline 1.3: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
   • Please take the time to read the Intent of Guideline 1.3 https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation.html"The purpose of this guideline is to ensure that all information is available in a form that can be perceived by all users, for example, spoken aloud, or presented in a simpler visual layout."

JF

On Thu, Mar 15, 2018 at 1:04 PM, Mike Gower notifications@github.com wrote:

Please feel free to respond to the ongoing CfC about moving 1.3.4

Thanks, I did. But how can "Common Purpose" and things to do with meaning not more logically fall under the Understandable principle as opposed to the Perceivable principle?

Principle 3: Understandable - Information and the operation of user interface must be understandable.

Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-373470436, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c6RZcbVLZv1ZM1qNMft10oDhhCbeks5teq0fgaJpZM4SsQFH .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

Intent of Guideline 1.3.

The purpose of this guideline is to ensure that all information is available in a form that can be perceived by all users...

Maybe we have a different definition of "perceivable". I think of it as being about using ones senses. Many of the proposed uses of Common Purpose I've heard are about manipulating something for understanding, not for senses. A user can perceive that a label says Banana. She needs to have the meaning of Banana clarified -- it's a fruit, etc.

As noted before, the POUR model has a lot of unfortunate overlap. We are often going to be in a situation (especially with more complex matters) where more than one principle and certainly more than one guideline can be invoked for relevance.

Is the content possibly going to be adapted? Sure, but you can say that about almost anything in 2.0. You adapt content to make it operable, perceivable and understandable for different users in different situations.

Looked at hierarchically, Understandable>Meaningful is clearly relevant to the topic of COGA. If the Adaptable guideline was under both Perceivable and Understandable principles, I suspect there wouldn't be a lot of disagreement that Understandable>Adaptable would be the best fit of all. I don't think we have that option, so dispassionately, the Understandable>Meaningful just seems like a lot better fit for a lot more future topics, including Common Purpose.

[johnfoliot]

A user can perceive that a label says Banana. She needs to have the meaning of Banana clarified -- it's a fruit, etc.

Maybe, sometimes. Or maybe-not; perhaps due to a cognitive issue, you write Banana, but they see naBnaa. In that scenario [alt: banana icon] disambiguates the label so that they can perceive what the label really is seeking. (While also noting this particular strawman is nonsensical - a label for a form input of "Banana"?)

Maybe we have a different definition of "perceivable".

​Definition of Perceive​: http://www.dictionary.com/browse/perceive

1. to become aware of, know, or identify by means of the senses:

2. to recognize, discern, envision, or understand: << ​ [JF: ​and ​here-in lies the bigger problem...]​

Synonyms for ​Perceiv​e: http://www.thesaurus.com/browse/perceive

• discern
• distinguish ​- feel
• grasp
• identify
• observe
• realize
• recognize

• regard

  ​> As noted before, the POUR model has a lot of unfortunate overlap. We are often going to be in a situation (especially with more complex matters) where more than one principle and certainly more than one guideline can be invoked for relevance.​

​I completely agree.​

The broader intent of this SC from the get-go was, however, to allow for forms of personalization, of which overlaying icons on form inputs is but a fraction of the need. But holistically, the COGA TF and the Personalization TF both are focusing on providing metadata at the element level for, to their needs, a far greater Perceivablity issue: if I can't first perceive what the letters mean, THEN I cannot understand what is being asked for. (It's an A >> B problem)

Yes, there is overlap (Cognition = Perceivability + Understanding), and today SC 1.3.4 has potential "early" wins in the "Understanding" column, but it also has longer-term goals that we are building towards that fall much closer to the "Perceivable" column - using metadata for Personalization.

Re-arranging the deck chairs at this point in time just feels wrong: we've proceeded this far with this SC requirement as a "Perceivable" requirement, and moving it under a different Principle transcends (IMO) simply editorial changes at this late (CR) date. As Michael Cooper noted on today's call, it may involve going all the way to TimBL and re-starting our CR process (and for what real gain? A more pedantic interpretation/differentiation between Perceiving and Understanding?)

Given that we already agree that there is significant overlap here, I struggle to see the value of that activity, especially in light of our tight deadline and the amount of work we still haven't started on, never-mind "approved" - is this really the hill to be fighting for? (And yes, I recognize the irony of that question, because y'all know I'm fighting hard to leave this as is...)

JF

On Thu, Mar 15, 2018 at 2:32 PM, Mike Gower notifications@github.com wrote:

Intent of Guideline 1.3.

The purpose of this guideline is to ensure that all information is available in a form that can be perceived by all users...

Maybe we have a different definition of "perceivable". I think of it as being about using ones senses. Many of the proposed uses of Common Purpose I've heard are about manipulating something for understanding, not for senses. A user can perceive that a label says Banana. She needs to have the meaning of Banana clarified -- it's a fruit, etc.

As noted before, the POUR model has a lot of unfortunate overlap. We are often going to be in a situation (especially with more complex matters) where more than one principle and certainly more than one guideline can be invoked for relevance.

Is the content possibly going to be adapted? Sure, but you can say that about almost anything in 2.0. You adapt content to make it operable, perceivable and understandable for different users in different situations.

Looked at hierarchically, Understandable>Meaningful is clearly relevant to the topic of COGA. If the Adaptable guideline was under both Perceivable and Understandable principles, I suspect there wouldn't be a lot of disagreement that Understandable>Adaptable would be the best fit of all. I don't think we have that option, so dispassionately, the Understandable>Meaningful just seems like a lot better fit for a lot more future topics, including Common Purpose.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-373496666, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c7IqjtMAz-WBpc70C1o2dAphqufjks5tesHbgaJpZM4SsQFH .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[bruce-usab]

I am open to a broad argument that Personalization is so fundamental that it belongs under Perceivable rather than Understandable. But with the Guidelines we have now in 2.0, SC 1.3.4 as phrased in the 2.1 CR is clearly misplaced.

So how about adding a Guideline 1.5 for Personalization and renumbering 1.3.4 as 1.5.1?

JF wrote:

The broader intent of this SC from the get-go was, however, to allow for forms of personalization

I don’t see how the broader intent (the behind-the-scenes sausage making) is relevant. The text of 2.1 needs to stand on it own. The current placement of 1.3.4 as it currently worded is exceptionally weak.

[johnfoliot]

Hi Bruce,

We could have a beer and debate whether or not it's "clearly misplaced", but to your suggestion, I could certainly live with that editorial change as I think it does address the debate at hand.

[mbgower]

So how about adding a Guideline 1.5 for Personalization

My issue with this is that personalization can cover a a lot more considerations than just the way it's used being proposed with the COGA spec.

Say to compensate for my poor fine motor control, through personalization I increase the target size of every single button by 5 pixels around its border without affecting the visual presentation at all (which I think is a realistic scenario). There is nothing perceivable about that. It is strictly Operable.

But if you've made an Guideline called Personalization, it suggests all SCs to do with personalization be shoved into Perceivable. That's a really an issue. In the same way that "adaptable" can be a means to achieve every principle, so can "personalization". I'd argue it was a mistake to use Adaptable, and redoing the same issue with Personalization is going to make it worse, not better.

[awkawk]

@bruce-usab, @mbgower Setting aside the question of whether we can add a new guideline in CR for a moment, I'm struggling if it is the right thing to do, as Mike seems to be above.

I suspect that any time that there is a need for additional information to be added for the benefit of accessibility that there is a possible personalization angle. For 1.1.1 the addition of alt text allows the possibility of a user having that text displayed, for 1.3.1 there are many personalization possibilities... On the last call someone (Mike?) ran through options across POUR that could touch personalization, which makes me think that there is not a single right place for the concept to live in WCAG 2.x.

[alastc]

Ok Michael, challenge accepted, I'll put my Information Architecture hat on.

Taking a little step back, we've got multiple topical slices we're trying to use, perhaps we can prioritise those and then see what falls out? By topical slices, I mean the method of categorization, e.g. benefit to user, method of implementation etc.

I think the previous 2.0 prioritization is something like this (from working backwards from the result), but happy to be corrected by the longer serving members:

1. User benefit, e.g. the benefit of resize-text is that the content is then perceivable.
2. Content trait, e.g. the content is distinguishable, navigable, adaptable.
3. Method of the user, e.g. zooming/increasing text size in order to make it distinguishable
4. User's technology, e.g. are they using a screenreader.
5. Author's technique, e.g. are you editing code, or changing the text content, etc.

The last two categories aren't very obvious in WCAG 2.0 as it aims for technology agnosticism, but there are strong hints in the groupings. It is no coincidence that the new SCs from the task forces correlated under particular sections.

Updated (2018-03-19): the categories tend to work if you can say:

The content is [level 1] because it is/has/provides [level 2] by/with/using [level 4].

E.g.

• The content is perceivable because it has text alternatives using non-text content.
• The content is perceivable because it is distinguishable using contrast.

I.e. Level 1 should be the user-benefit, level 2 the content trait, level 3 the author technique.

So trying to be systematic: The end-user benefit trumps user-method, which trumps user-technology, which trumps technique. (No political jokes please.) Rattling through Michael's list (all my opinion, not chairing):

• Identify Common Purpose, assuming we are talking about adding icons then the user benefit is 'understandable' (you can perceive the text, the icons help understanding), but then it falls down at the second level. It isn't about readability (although I agree that's closest in 3.x now), we'd need another 3.x guideline around personalisation or adaptability. 3.4 Personalisation?

However, if that extra section isn't an option, I'd want to stick with the current location as that at least works at the second level.

• Identify Purpose, as above.

• Reflow, it is the user adapting things, but the user-benefit trumps the method in the categorization, so I'd argue for it's current place. Also, the 1.3 are around the user-technology automtically adapting things, rather than over-riding.

NB: if you really think this should go under adaptable, then so should ID common purpose, that would be the logic.

• Text spacing, as per reflow, current place.

• Content on Hover of Focus. Tricker, but the user-benefit is that you can perceive the content. You aren't having trouble operating it, but it's whether you can perceive things whilst operating it, therefore current place.

• Animation from Interactions, definitely operable, but difficult after that. It isn't about timing, but then, pause/stop/hide isn't really either. I agree with the wish to put it in seizures and broaden the title, but I think that's off-limits in 2.1. It doesn't result in seizures, so without a title change it would be confusing there, so I'd recommend it stays where it is.

• Character Key Shortcuts, I know the SC text only mentions keyboard, but the user benefit is operable > navigation for voice input, I can't see the user-benefit for "keyboard", so I prefer it's current location. I'm afraid I missed the Additional Modalities suggestion, but would that group all the new pointer, sensor and voice input ones? If so, that might be a bigger change than we can make at the moment.

• Label in Name, as above.

• Concurrent Input Mechanisms, as above (too big a change)

• Status Changes, I'm a bit less familiar with this one, but I think the benefit is that you can perceive a status change away from your focus? For me that's 1.3.x SC, or possible 4.1.x as a fall back.

But one final point: Apart from standards nerds (in the nicest possible way), everyone else in the world treats these as a list of stuff to do (if we're lucky). It isn't the end of the world.

[mraccess77]

I agree @awkawk - 1.3.1 would allow users with low vision to personalize the site by using stylesheets -- so to a person with low vision 1.3.1 really promotes personalization in my opinion. For Silver instead of having rigid groups we might tag criteria to the categories that they apply to.

[mbgower]

Thanks for the look, @alastc . A few responses:

we'd need another 3.x guideline around personalisation or adaptability. 3.4 Personalisation

Which is sorta what I proposed with Understandable> Meaningful (which I believe is the more elegant solution -- just replace Readable with Meaningful, as per my comment).

Content on Hover of Focus. You aren't having trouble operating...

It think it enters into it. There's a lot of operation in there, hence the need to cover info on dismissing.

Animation from Interactions: I agree with the wish to put it in seizures and broaden the title, but I think that's off-limits in 2.1

I'm not sure it needs to be off-limits. We aren't talking about anything that would affect numbering of existing or new SCs. It wouldn't affect Principles (no affect on the POUR model). All that would be affected would be an alteration to VPATs and reports using the VPATs, where the section heading would change. What would be the negative impact of calling it something like: Seizures and Physical Reactions

Character Key Shortcuts.... the user benefit is operable > navigation for voice input, I can't see the user-benefit for "keyboard",

Yes, it may cover navigation, but it also covers a lot more operation. And it absolutely covers keyboard, in fact I'd argue this stayed in because several of us advocated that it wasn't just a speech input oddity. The speech control is riding on the keyboard interaction.

I missed the Additional Modalities suggestion, but would that group all the new pointer, sensor and voice input ones?

No, it would just contain the few that are not Pointer:

• Label in Name
• Concurrent Input Mechanisms
• Character Key Shortcuts (optionally, if 2.1 isn't considered a correct destination).

It is a much more elegant (and extendable) model than shoving a bunch of stuff into Pointer as a poor substitute.

Apart from standards nerds (in the nicest possible way), everyone else in the world treats these as a list of stuff to do (if we're lucky). It isn't the end of the world.

Agreed, which is why I've let it more or less ride for the last four months. But given the large amount of time spent on 1.3.4, it seemed like we were considering this important.

[bruce-usab]

Based on the excellent discussion here, I am happy to retract my suggestion that adding a new Guideline might solve the problem!

@awkawk (emphasis added):

I suspect that any time that there is a need for additional information to be added for the benefit of accessibility that there is a possible personalization angle. For 1.1.1 the addition of alt text allows the possibility of a user having that text displayed

I agree, but I think the that the need for additional information (supplied by the content author) is what really sets Perceivable apart. For 1.1.1, and screen reader users, the addition of alt text allows the possibility of reading the page at all. Other benefits (such as having that text displayed) are not as essential, and might not even be Level AAA on their own. Yes, for 1.3.1 there are many personalization possibilities, but it is under Perceivable because things like non-trivial data tables become insensible without additional (author supplied) information.

If I have a set of address fields that (with some future UA) transforms into a photo of my home next to a bright green checkmark, yes that is clearly an adaptation. But is it additional information? I do not think so. It is just the same information, but presented in a way that more understandable to the user.

@alastc:

But one final point: Apart from standards nerds (in the nicest possible way), everyone else in the world treats these as a list of stuff to do (if we're lucky).

I agree. In the training I do, it would be hard for me to spend less time on POUR. But I would argue that a significant aspect of what allowed 2.0 to be as widely adopted as it is, is the attention the working group gave to small details like this.

[johnfoliot]

For Silver instead of having rigid groups we might tag criteria to the categories that they apply to.

A huge +1 - I really like that idea Jon (it's "tagging" SC with, erm... metadata. ;-) )

JF

On Thu, Mar 15, 2018 at 5:19 PM, Jonathan Avila notifications@github.com wrote:

I agree @awkawk https://github.com/awkawk - 1.3.1 would allow users with low vision to personalize the site by using stylesheets -- so to a person with low vision 1.3.1 really promotes personalization in my opinion. For Silver instead of having rigid groups we might tag criteria to the categories that they apply to.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-373540896, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c9KZnaGygX5jhdXGdDMgZhz8q2Pnks5teujhgaJpZM4SsQFH .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[johnfoliot]

but it is under Perceivable because things like non-trivial data tables become insensible without additional information.

If I have a set of address fields that (with some future UA) transforms into a photo of my home next to a bright green check mark, yes that is clearly an adaptation. But is it additional information? I do not think so.

Hi Bruce,

I'd push back on that slightly. In my previous response yesterday, Mike introduced the straw-man of the label of Banana for a form input, and there I suggested that for some users with cognition issues, the addition of a banana icon made the (scrambled text of) naBnaa now no longer, in your words, "insensible". The COGA TF have written about this here: https://rawgit.com/w3c/coga/master/issue-papers/symbols-non-verbal.html

If I may, you appear to be working from the assumption that all users can read words like "Postal Code" (which is a field for your "Home" inputs collection) and thus perceive what is being asked of them, but that simply isn't true for all users. Dyslexics might read it as talPos Cdeo, where-as for some forms of users who are Autistic, they might simply blank out https://musingsofanaspie.com/2013/03/07/the-case-of-the-missing-words/ on those words.

For 1.1.1, the addition of alt text allows the possibility of reading the page,

​... using a screen reader, yes. But without a screen reader, alt text is effectively hidden for most users, unless you use a different tool to further surface that text.

Taking the same premise, and re-examining it: "For 1.3.4, the addition of symbols allows the possibility of reading the page (for users with cognition issues​)."

Remember as well, that adding symbols to pages is but one form of personalization, and likely the most obvious form in this example, but the over-arching goal has always been to add element-level meta-data to controls (an input is a control, right?) so that, just like alt text, machines can provide 'alternatives' to what the author has furnished or intended in their visual design. In fact, I'd go so far as to suggest that for some users, the provision of symbols is as critical to them as the provision of alt text is to non-sighted users (which, as you note, is clearly a Perceivable-class Success Criteria).

JF

On Fri, Mar 16, 2018 at 7:47 AM, John Foliot john.foliot@deque.com wrote:

For Silver instead of having rigid groups we might tag criteria to the categories that they apply to.

A huge +1 - I really like that idea Jon (it's "tagging" SC with, erm... metadata. ;-) )

JF

On Thu, Mar 15, 2018 at 5:19 PM, Jonathan Avila notifications@github.com wrote:

I agree @awkawk https://github.com/awkawk - 1.3.1 would allow users with low vision to personalize the site by using stylesheets -- so to a person with low vision 1.3.1 really promotes personalization in my opinion. For Silver instead of having rigid groups we might tag criteria to the categories that they apply to.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-373540896, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c9KZnaGygX5jhdXGdDMgZhz8q2Pnks5teujhgaJpZM4SsQFH .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

Okay, I'm going to break out 1 discussion point here, with three considerations:

Renaming guidelines

• renaming Seizures to Seizures and physical reactions
• renaming Additional sensor inputs to Other modalities
• under Understandable, renaming Readable to Meaningful

For Seizures, I think it's pretty easy to argue that appending a couple of words to an existing Guideline will not break anything. It gives an obvious home for "Animation from Interactions", and immediately improves the context for what that SC is addressing.

Renaming "Additional sensor inputs" is a new idea, but given it is new in 2.1 seems doable. Making the slightly broader category of "Other modalities" allows us to give a home for "Label in Name" and Character Key Shortcuts (optionally, if moving to 2.1 gets no traction) and leads us to an easier place to put non-keyboard and non-pointer things going forward.

NOTE: I'll digress for a moment, and point out that having seen Status Changes go to 4.1, Label in Name also seems like a possible candidate for Robust. In fact, give the post John just puts up, you could almost argue the 1.3.4/5 ones are candidates too. Just another idea.

I've given my take on why replacing an existing guideline word is also trivial impact.. Make it Meaningful (formerly Readable) in the text, if necessary. This lets us put both of the Purpose SCs into Understandable. There seems to be less buy in than I hoped on this, but it does offer a path forward. I would argue that even if we just made the wording change for now, it is a better Guideline name when one considers the SCs it holds.

So, there you are three various ways to tackle some of the more nagging classifications. They're not all-or-nothing; I've listed them in order of what I suspect is ease of argument. Thanks for your thoughts.

[alastc]

Just to summarise in situe, I think that would look like this, with asterix at the start of each change.

1. Perceivable
    1.1 Text Alternatives
...
    1.3 Adaptable
        1.3.1 Info and Relationships
        1.3.2 Meaningful Sequence
        1.3.3 Sensory Characteristics
*       1.3.4 Status Changes (I’ve no problem with 4.1.x for this)
    1.4 Distinguishable
        1.4.1 Use of Color
        1.4.2 Audio Control
...

2. Operable

...
*   2.3 Seizures and physical reactions
        2.3.1 Three Flashes or Below Threshold
        2.3.2 Three Flashes
*       2.3.3 Animation from Interactions
    2.4 Navigable
        2.4.1 Bypass Blocks
...
    2.5 Pointer Accessible
        2.5.1 Pointer Gestures
        2.5.2 Pointer Cancellation
        2.5.3 Target Size
*   2.6 Other modalities
        2.6.1 Motion Actuation
        2.6.2 Orientation
*       2.6.3 Label in Name
*       2.6.4 Character Key Shortcuts
*       2.6.5 Concurrent Input Mechanisms

3. Understandable

*   3.1 Meaningful
        3.1.1 Language of Page
        3.1.2 Language of Parts
        3.1.3 Unusual Words
        3.1.4 Abbreviations
        3.1.5 Reading Level
        3.1.6 Pronunciation
*       3.1.7 Identify Input Purpose
  (just throwing ‘input’ in – if we add others, it needs to still work)
*       3.1.8 Identify Purpose
    3.2 Predictable
...

[mbgower]

Just to summarise in situe

Yes, @alastc , that is a summary of where I got to in the journey of this issue thread. I emphasize that it doesn't have to be an 'all or nothing' proposal. Each of these Guideline changes would realize benefit. Some will be easier to get buy-in on than others.

Oops, with one correction. I'm suggesting Concurrent Input Mechanisms could also benefit from being under Other Modalities.

[Ryladog]

Mike,

I think this is something we should talk about at the F2F,

One note: In general I do not like a Guideline that uses 'other' or 'additional' such as

Other modalities, or Additional sensor inputs.

I think each Guideline must be descriptive of what it contains, stand alone......I know, not easy....

• katie

[alastc]

Katie,

I'd generally agree with not using a "bucket term" like 'other' (see number 4 here). Something I just noticed is that the categories tend to work if you can say:

The content is [level 1] because it is/has/provides [level 2] by/with/using [level 3]

E.g.

• The content is perceivable because it has text alternatives using non-text content.
• The content is perceivable because it is distinguishable using contrast.
• The content is understandable because it is meaningful by Identify(ing) input purpose(s).

Not perfect (e.g. Seizures should be Prevents seizures), but a useful rule of thumb.

In thinking of an alternative to "other modalities":

• The content is operable because it [is modality independent] using Label(s) in Name(s).
• The content is operable because it [is input agnostic] using Concurrent Input Mechanisms.

Spit-balling: Modality independence, input independence, input agnostic... hmm, difficult, complex words which don't have nice synonyms.

[mbgower]

I'd generally agree with not using a "bucket term" like 'other'

@alastc and @Ryladog, I was wondering if a single Guideline instead of Pointer Accessible and Additional sensor inputs might be one solution for this.

How about one of these?

• Non-Keyboard Operation
• Non-Keyboard Accessible
• Accessible operation

The first 2 are siblings to Keyboard Accessible which I think work fairly well for existing and future modality considerations. The last is a bit muddier, given that Keyboard Accessible is also accessible operation.

[alastc]

I'd prefer Non-keyboard Accessible, as the opposite twin to Keyboard Accessible. That could encompass all the pointer & sensor ones.

[awkawk]

[Official WG Response]

@mbgower - This long discussion was ultimately boiled down into changes in the location of Animation for Interaction (implemented in https://github.com/w3c/wcag21/commit/84b3a6eda28c89fa3cd93f63a9a708ad92bef432 as a result of CFC on 4/5/2018) and changes to the location of Status Changes to 4.1.3 (via a separate CFC on the same date).

[awkawk]

The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory.

[Ryladog]

Ah, no. I do not agree with that. This was also about the name of the Guideline for all things not keyboard accessible. This should not be closed

[Ryladog]

This should not be closed. Please add it to Agenda for next Tuesday.

On Thu, Apr 5, 2018, 9:54 PM Andrew Kirkpatrick notifications@github.com wrote:

Closed #806 https://github.com/w3c/wcag21/issues/806.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#event-1560036076, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyptAAPxPSsMVvvcUc_9AtKQJkMTyks5tlsrvgaJpZM4SsQFH .

[awkawk]

@Ryladog This was a CFC of the group, discussed at the face to face at CSUN and approved via the CFC.

[Ryladog]

Nope, only part of it was, the other part wasn't discussed. Remember?

On Thu, Apr 5, 2018, 10:26 PM Andrew Kirkpatrick notifications@github.com wrote:

@Ryladog https://github.com/Ryladog This was a CFC of the group, discussed at the face to face at CSUN and approved via the CFC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-379130878, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyidx4jQpntHUdJ_k01j7Q5bZ7UjHks5tltJngaJpZM4SsQFH .

[mbgower]

I'd side with @Ryladog on this; the CFC on 806 proposed the first of my three suggestions

That one was successful. I listed them in what I suspected was increasing order of effort with which to get buy-in, but I didn't hear or see a lot of dismissal of at least the second one (which morphed into the notion of a merged Non-Keyboard Accessible guideline). To make things easy, I'm going to break each of the other proposals into separate issues https://github.com/w3c/wcag21/issues/852 https://github.com/w3c/wcag21/issues/853

[awkawk]

@mbgower We discussed all of these options at the F2F at CSUN and the only parts that we had consensus on are the ones that were CFC'd.

If you would like to mark this as defer or something we can do that but there isn't much time left to get consensus on other changes that have been discussed and did not have it yet.

[Ryladog]

I recall that there was no time left to discuss this part of this topic, after you have gotten the GL name change for you wanted for Seizures and moving the Animations from Interactions SC, - and - that you said the WG could discuss the concerns of Mike and I on email after the F2F. I remember this clearly.

[Ryladog]

I recall that there was no time left to discuss this part of this topic, after you have gotten the GL name change for you wanted for Seizures and moving the Animations from Interactions SC, - and - that you said the WG could discuss the concerns of Mike and I on email after the F2F. I remember this clearly. @nitedog https://github.com/nitedog

katie

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-379312388, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqymQy7FlRSPu6_HAC3xjuj-S9zHPsks5tl51xgaJpZM4SsQFH .

[awkawk]

@Ryladog

I recall that there was no time left to discuss this part of this topic, after you have gotten the GL name change for you wanted for Seizures and moving the Animations from Interactions SC, - and - that you said the WG could discuss the concerns of Mike and I on email after the F2F. I remember this clearly. @nitedog https://github.com/nitedog

Until now, was this raised on the list following CSUN?

[Ryladog]

Some of us, including you, have been extremely busy since CSUN. The comment closing posted 16 hours ago (see below) says there is 3 days to comment. I am commenting. This topic needs to be reopened.

"The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory. "

katie

Katie Haritos-Shea Principal ICT Accessibility Architect

WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = CPWA http://www.accessibilityassociation.org/cpwacertificants

Cell: 703-371-5545 <703-371-5545> | ryladog@gmail.com ryladog@gmail.com | Oakton, VA | LinkedIn Profile http://www.linkedin.com/in/katieharitosshea/

People may forget exactly what it was that you said or did, but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.

On Fri, Apr 6, 2018 at 12:23 PM, Andrew Kirkpatrick < notifications@github.com> wrote:

@Ryladog https://github.com/Ryladog

I recall that there was no time left to discuss this part of this topic, after you have gotten the GL name change for you wanted for Seizures and moving the Animations from Interactions SC, - and - that you said the WG could discuss the concerns of Mike and I on email after the F2F. I remember this clearly. @nitedog https://github.com/nitedog https://github.com/nitedog

Until now, was this raised on the list following CSUN?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-379320406, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyjn001Xo-MQHqUU1AbS5Lky1gylgks5tl6SEgaJpZM4SsQFH .

[awkawk]

The comment closing posted 16 hours ago (see below) says there is 3 days to comment. I am commenting. This topic needs to be reopened.

It isn't your issue to make additional comments on, it is @mbgower's. Your main opportunity was during the CFC, or if Mike isn't happy with the response (which seems likely because of his comments here but also seems unlikely in that he voted for the CFC).

[WayneEDick]

Reflow and text spacing are adaptations of data. Reflow does not make text distinguishable it makes it visible. You can't start distinguishing until you can see. That being said, a level AA Reflow anywhere does the job. It should be level A because it is as important as screen readers are to non visual access, and we know it is completely doable and testable.

I agree with Mike but I think this can be postponed until Silver.

Wayne

On Fri, Apr 6, 2018 at 10:42 AM, Andrew Kirkpatrick < notifications@github.com> wrote:

The comment closing posted 16 hours ago (see below) says there is 3 days to comment. I am commenting. This topic needs to be reopened.

It isn't your issue to make additional comments on, it is @mbgower https://github.com/mbgower's. Your main opportunity was during the CFC, or if Mike isn't happy with the response (which seems likely because of his comments here but also seems unlikely in that he voted for the CFC).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/806#issuecomment-379325817, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-vfeeIkqH3gi4hK5KfC8BtBUk7jks5tl6kcgaJpZM4SsQFH .