Re: Re[2]: Move 3.2.6 Status changes to the Adaptable guideline?

The addition of "other" in front of properties for Status Changes is a 
friendly editorial change from my perspective, but don't want to get 
distracted by the important question of whether we have all the new SCs in 
the right guidelines!

The other items Steve and I agreed on:
move 'Animation from Interactions' out of Operable>Enough Time. See 
comments on possible options.
move 'Character Key Shortcuts' to Operable>Keyboard Accessible
move 'Concurrent Input Mechanisms'  out of Operable>Pointer Accessible.

Steve also did not disagree with me about:
move 'Reflow' and 'Text Spacing' from Perceivable>Distinguishable to 

A key part of my analysis was that a new Guideline called something like 
Operable > Additional Modalities could contain a number of orphans. Given 
the unresolved discussion on the Sensors guidelines language, this is one 
possible path to take for it as well.

Michael Gower
IBM Accessibility

1803 Douglas Street, Victoria, BC  V8T 5C3
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034

From:   "Joshue O Connor - InterAccess" <>
To:     "Michael Gower" <>, "Andrew Kirkpatrick" 
Cc:     WCAG <>
Date:   2018-01-12 12:00 PM
Subject:        Re[2]: Move 3.2.6 Status changes to the Adaptable 

Like it, one suggestion..While largely editorial - I think it is clearer.

"In content implemented using markup languages, status messages can be 
programmatically determined through role or other properties so the 
messages can be presented to the user by assistive technologies without 
receiving focus."



------ Original Message ------
From: "Michael Gower" <>
To: "Andrew Kirkpatrick" <>
Cc: "WCAG" <>
Sent: 12/01/2018 19:02:50
Subject: Re: Move 3.2.6 Status changes to the Adaptable guideline?

I had a whole list of such suggestions back in early December, which Steve 
responded to. Pasting here for reference...

RE: SC classificationsMichael Gower to: Repsher, Stephen J 2017-12-08 
07:55 AM
From: "Michael Gower" <>
To: "Repsher, Stephen J" <>
Cc: WCAG <>
Archive: This message is being viewed in an archive.

Thanks, Steve. I think your comments can stand on their own, but I wanted 
to respond to this one:

>If this is moved, then so should 1.4.4.
We cannot touch any existing 2.0 SCs in this exercise. I believe that was 
demonstrated when David proposed to move a couple of 2.0 AAA SCs to create 
a more consistent numbering and classification in 2.1. That said, we 
shouldn't perpetuate potentially poor historical classifications with new 
decisions in this round. If we think a new SC fits better somewhere, it 
should go there.
I think it is likely there will end up being a 2.2, and to the degree that 
we can keep future modalities and developments in mind, I think we should 
try to make our classification as aligned with the POUR principles as 
possible in this round, regardless of curiosities in 2.0.

From:        "Repsher, Stephen J" <>
To:        Michael Gower <>, WCAG <>
Date:        2017-12-07 10:19 AM
Subject:        RE: SC classifications

Thanks, Mike.  Good analysis.  I put comments where I agree or disagree 
From:Michael Gower [] 
Sent: Thursday, December 07, 2017 11:00 AM
To: WCAG <>
Subject: SC classifications
Assuming the Dec 7 version of this 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 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.
[Steve] I disagree and think Adaptable is a good fit.  The techniques here 
such as microdata or other attributes are not part of the default 
presentation.  Rather, they exist so a user can transform the content to 
familiarities that work for them.  WebAIM’s article is focused on physical 
disabilities, but the addition of this SC is an appropriate application 
for the cognitive space.

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.
[Steve] If this is moved, then so should 1.4.4.  Same grayness applies as 
with Text Spacing.

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." 
[Steve] I could go either way on this (and it was discussed on the issue 
that resulted in renaming this SC from Adapting Text).  Guidelines 1.3 and 
1.4 do not exist as black and white.

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 
[Steve] I disagree.  This is Primarily about making it easier (or 
possible) to see the additional content and whatever it may cover up 
because of lack of lack of consideration for magnified views, large 
pointers, etc.  That said, when the triggers or additional content have 
operable components, there is some principle overlap.

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.
[Steve] Agree it doesn’t fit.

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.
[Steve] Agree.

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.
[Steve] Agree navigable is not a great fit as the shortcut doesn’t 
necessarily have anything to do with navigation or finding content.

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.
[Steve] I disagree.  For a speech user, this is all about jumping to the 
control efficiently.  (For a low vision user, it has Understandable 
benefits, but that’s secondary).

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

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.
[Steve] Agree.

Status Changes - under Operable>Predictable. I think this actually makes 
more sense under Perceivable. Subcategory? Probably Distinguishable, or 
maybe Adaptable.
[Steve] Strongly agree.  This belongs under Adaptable as it is about the 
messages being transformed into audio or Braille at the appropriate time.

Michael Gower
IBM Accessibility

1803 Douglas Street, Victoria, BC  V8T 5C3
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034

From:        Andrew Kirkpatrick <>
To:        WCAG <>
Date:        2018-01-12 10:30 AM
Subject:        Move 3.2.6 Status changes to the Adaptable guideline?

Steve has a proposed change to move 3.2.6 (Could look like this:

What do people think?
(my take is that it might also make sense at 4.1.3, but am not passionate 
about that).
Andrew Kirkpatrick
Group Product Manager, Accessibility

Received on Friday, 12 January 2018 20:18:33 UTC