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

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."

Thanks

Josh

------ Original Message ------
From: "Michael Gower" <michael.gower@ca.ibm.com>
To: "Andrew Kirkpatrick" <akirkpat@adobe.com>
Cc: "WCAG" <w3c-wai-gl@w3.org>
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
>Cc: WCAG
>From: "Michael Gower" <michael.gower@ca.ibm.com>
>To: "Repsher, Stephen J" <stephen.j.repsher@boeing.com>
>Cc: WCAG <w3c-wai-gl@w3.org>
>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" <stephen.j.repsher@boeing.com>
>To:        Michael Gower <michael.gower@ca.ibm.com>, WCAG 
><w3c-wai-gl@w3.org>
>Date:        2017-12-07 10:19 AM
>Subject:        RE: SC classifications
>
>--------------------------------------------------------------------------------
>
>Thanks, Mike.  Good analysis.  I put comments where I agree or disagree 
>below.
>
>
>
>Steve
>
>
>
>From:Michael Gower [mailto:michael.gower@ca.ibm.com]
>Sent: Thursday, December 07, 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://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_wcag21_guidelines_&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=LsubWLi77Ps2I4ozl8IIrEWPNnvGqbYUvZKIHEOX4ls&s=b-6lz_0O5lPdbw98CZy0hFmQTjNq_Ioa64aNh-Oc9Xs&e=>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://urldefense.proofpoint.com/v2/url?u=https-3A__webaim.org_articles_pour_perceivable&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=o0daxkHGHraHNw9i2iAgh1-u02Hps_TQhDkH1KZHuuQ&m=rIrBWgUBNWnwym9hiugHYfacotAbvfTnviL1q9Hicek&s=mE0tBgb0mJwrRVbpQEmFEmciGz68ZaeaLtizrB4g6ag&e=>topic. 
>Surely its primary purpose is Understandable 
><https://urldefense.proofpoint.com/v2/url?u=https-3A__webaim.org_articles_pour_understandable&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=o0daxkHGHraHNw9i2iAgh1-u02Hps_TQhDkH1KZHuuQ&m=rIrBWgUBNWnwym9hiugHYfacotAbvfTnviL1q9Hicek&s=RTy2Kd_gfBqCPG-s5eEfKvPUlb7SVkByV4VyuIn5NTk&e=>. 
>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 something.
>
>[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 
>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.
>
>[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.
>
>
>
>Cheers,
>Michael Gower
>IBM Accessibility
>Research
>
>1803 Douglas Street, Victoria, BC  V8T 5C3
>gowerm@ca.ibm.com
>voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034
>
>
>
>
>
>
>From:        Andrew Kirkpatrick <akirkpat@adobe.com>
>To:        WCAG <w3c-wai-gl@w3.org>
>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:http://rawgit.com/w3c/wcag21/status-changes-to-new-guideline/guidelines/index.html#status-changes)
>
>
>
>What do people think?
>
>
>
>(my take is that it might also make sense at 4.1.3, but am not 
>passionate about that).
>
>
>
>Thanks,
>
>AWK
>
>
>
>Andrew Kirkpatrick
>
>Group Product Manager, Accessibility
>
>Adobe
>
>
>
>akirkpat@adobe.com
>
>http://twitter.com/awkawk
>
>
>
>