- From: David MacDonald <david100@sympatico.ca>
- Date: Fri, 12 Jan 2018 16:17:12 -0500
- To: Michael Gower <michael.gower@ca.ibm.com>
- Cc: Joshue O Connor - InterAccess <josh@interaccess.ie>, Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAAdDpDbzdw1+GAu-EKWa2YqxN0yOxwCfceYoPRkpOYpK_+Sczw@mail.gmail.com>
I'm fine to move it to 1.3.4 Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613.235.4902 LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd GitHub <https://github.com/DavidMacDonald> www.Can-Adapt.com <http://www.can-adapt.com/> * Adapting the web to all users* * Including those with disabilities* If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html> On Fri, Jan 12, 2018 at 3:17 PM, Michael Gower <michael.gower@ca.ibm.com> wrote: > 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 > Perceivable>Adaptable > > - > 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 > Research > > 1803 Douglas Street, Victoria, BC > <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g> > V8T 5C3 > <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g> > gowerm@ca.ibm.com > voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034 > > > > From: "Joshue O Connor - InterAccess" <josh@interaccess.ie> > To: "Michael Gower" <michael.gower@ca.ibm.com>, "Andrew > Kirkpatrick" <akirkpat@adobe.com> > Cc: WCAG <w3c-wai-gl@w3.org> > Date: 2018-01-12 12:00 PM > Subject: 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* > <michael.gower@ca.ibm.com>> > To: "Andrew Kirkpatrick" <*akirkpat@adobe.com* <akirkpat@adobe.com>> > Cc: "WCAG" <*w3c-wai-gl@w3.org* <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* > <michael.gower@ca.ibm.com>> > To: "Repsher, Stephen J" <*stephen.j.repsher@boeing.com* > <stephen.j.repsher@boeing.com>> > Cc: WCAG <*w3c-wai-gl@w3.org* <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* > <stephen.j.repsher@boeing.com>> > To: Michael Gower <*michael.gower@ca.ibm.com* > <michael.gower@ca.ibm.com>>, WCAG <*w3c-wai-gl@w3.org* <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* > <michael.gower@ca.ibm.com>] > *Sent:* Thursday, December 07, 2017 11:00 AM > *To:* WCAG <*w3c-wai-gl@w3.org* <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 > <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g> > V8T 5C3 > <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g> > *gowerm@ca.ibm.com* <gowerm@ca.ibm.com> > voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034 > > > > > > From: Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com> > > > To: WCAG <*w3c-wai-gl@w3.org* <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* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__rawgit.com_w3c_wcag21_status-2Dchanges-2Dto-2Dnew-2Dguideline_guidelines_index.html-23status-2Dchanges&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=BgVlBw0-qEeFlo3fG57KHYgOiYXJFvv4YfNwMiY4m5s&s=NTO1bRo0BBSOyrbVbK6x-h9LksViqN1CPWLmkuV4DfM&e=> > ) > > > > 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* <akirkpat@adobe.com> > > *http://twitter.com/awkawk* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_awkawk&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=BgVlBw0-qEeFlo3fG57KHYgOiYXJFvv4YfNwMiY4m5s&s=nuEgs4p6TMMjw6JACb3MRL0tPacxQ1mVepayISotw7Y&e=> > > >
Received on Friday, 12 January 2018 21:17:41 UTC