- From: David MacDonald <david100@sympatico.ca>
- Date: Fri, 15 Jul 2016 00:53:18 -0400
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- CC: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <BLU437-SMTP4485FE00403BFB28D719F0FE330@phx.gbl>
And we would also have to address the issue that Detlev brought up about testing. This amalgamation might turn 2.1.1 into the new 1.3.1. 2.1.1 is already huge in my audit reports... and functional QA teams would have to test with keyboard AND Mobile screen readers, AND other "non-pointer devices", and if a failure is reported, remediation teams will have to go digging for what went wrong. I think there are some advantages of a separate 2.5 Guideline to deal with "pointers". John Foliot expressed an opinion about SC bloat. He wrote: "I am not that concerned about “bloat” – the requirements are the requirements are the requirements. The web as a platform has grown significantly more complex and sophisticated over the 8+ years since the original WCAG 2.0, and overall the developer’s toolbox has also grown exponentially. I don’t think it is unreasonable to then expect that accessibility requirements have also expanded in direct relationship to the level of complexity introduced by today’s modern web development practices...I’d suggest that [SC] filtering could be performed on web sites and/or within tools, as already demonstrated in the WCAG Quickref – I don’t think we need to worry about quantity as much as we need to ensure we have the right number: not too many, but not too few." https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JulSep/0200.html 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 Thu, Jul 14, 2016 at 10:36 PM, David MacDonald <david100@sympatico.ca> wrote: > I've tried to stay out of this thorny thread but when I understood that > one purpose of it is to replace the 2.5.1 mobile proposal, I realized I > need to ensure the concerns I had when trying to write 2.5.1 will be > addressed in this proposal. > 2.5.1 > Touch with Assistive Technology: All functions available by touch are > still available by touch after platform assistive technology that remaps > touch gestures is turned on. (Level A) > > From the very beginning of mobile a11y discussions, my most important > concern has been that when users turn on VO or Talkback on a mobile, the > conforming page will work. I'm concerned that the new language does not > require it to work with the AT layer running. But it is built on a hope > that if high level events are chosen, it WILL work with AT running. > > So I guess it's time we, as a task force, understand in a general way how > these layers of APIs and OS etc fit together in the mobile environment. > > Let me start it off based on our discussions with Chris today and my own > understanding from desktop a11y APIs and environments. I am fine with being > corrected if I've got some part of this wrong. We need to understand it to > make good decisions. > > We have basically have 3 layers of software on mobile devices. > > - kernel on the bottom > - OS level in the middle > - AT (and other software) running on top of that > > Chris tells us that Keyboard interface events are registered at the kernel > level and sent to the OS level as keyboard events. He says AT events are > registered at the AT level on the top of the stack and are either sent to > the kernel level as fake keyboard events or (as Patrick explains in this > thread) may just communicated straight to the OS level (i.e., "move focus > to next") bypassing the KB interface. > > Historically, most every AT used fake keyboard events but that is no > longer true, and now its a mix of fake keyboard events and direct > communication of events to the OS so we need to extend our requirements so > that these non-fake keyboard events are covered in ADDITION to keyboard. > Maybe in the future a Indie UI type of standard will fix the mess, but that > is nowhere in the near term, since the group was disbanded. > > So we have keyboard interface events coming from the bottom of the stack > and AT events coming from the top of the stack, and we want a SC that > covers it all. > > Patrick says that the sufficient technique will be to use high level > events (Onclick, onblur, etc) and therefore we won't need two techniques to > meet the SC. So we won't end up with this mess. > > -Sufficient technique A (for keyboard) AND Technique B (for AT) > > Anyway, the only way I could live with it is if Keyboard is explicitly > required > AND ensure that our proposal for 2.5.1 requiring functions to work when > platform AT is on > : > > Something like: > > "All functionality of the content is operable through non-pointer input > interfaces (which includes the keyboard interface), without requiring > specific timings.. (Level A)" > > NOTE: All functionality is still required to work with a keyboard as per > WCAG 2 > NOTE: All functions available by touch are still available by touch after > platform assistive technology that remaps touch gestures is turned on. > > Also, I think we would want to create a term in place "non-pointer event" > It's really clunky as Alastair said. > > 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 Thu, Jul 14, 2016 at 8:34 PM, Patrick H. Lauke <redux@splintered.co.uk> > wrote: > >> On 14/07/2016 23:43, David MacDonald wrote: >> >> . Say you and me decide to go into business. We create the "David and >>> Patrick magic hand gesture translator." It is assistive technology. >>> "Accessibility supported" language is intended to require pages to work >>> with assistive technology. This is not web content so WCAG no >>> requirements on it. HOWEVER, it is assistive technology, and therefore >>> if 2.1.1 applies to ALL non-pointer technologies, then it would have to >>> include this too. That is a very expansive rabbit hole I would say. Go >>> to CSUN and 2.1.1 would require web pages to work with EVERY Assitive >>> Technology. >>> >> >> The AT would hook into the OS/platform's standardised APIs (or hook into >> the UAs like browsers through additional plugins, like Dragon does for >> instance). There is (at least to my mind) a tacit understanding that UAs >> (including AT) need to work in a standardised and consistent way. Otherwise >> ANYTHING in WCAG could be up for discussion (e.g. we assume that UAs >> understand HTML). That would at least by my expectation, though I see WCAG >> dodges that bullet and/or gets itself muddled: >> >> "This topic raises the question of how many or which assistive >> technologies must support a Web technology in order for that Web technology >> to be considered "accessibility supported". The WCAG Working group and the >> W3C do not specify which or how many assistive technologies must support a >> Web technology in order for it to be classified as accessibility supported. >> This is a complex topic and one that varies both by environment and by >> language." >> [...] >> "The Working Group, therefore, limited itself to defining what >> constituted support and defers the judgment of how much, how many, or which >> AT must support a technology to the community and to entities closer to >> each situation that set requirements for an organization, purchase, >> community, etc." >> >> So if "accessibility supported" is not a phrase that can be applied to >> the assistive technology itself, fine to drop it. >> >> We addressed this in our 2.5.1 proposal >>> >>> "2.5.1 >>> Touch with Assistive Technology: All functions available by touch are >>> still available by touch after platform assistive technology that remaps >>> touch gestures is turned on. (Level A) >>> " >>> >>> The qualifier is that it is limited to " >>> platform assistive technology that remaps touch gestures" >>> . >>> >> >> Note that not so long ago (few years?), TalkBack didn't come as standard >> on Android and had to be downloaded/installed as a separate app. So even on >> mobile, it's not guaranteed to always be as cut and dry >> >> Now as we try to genericize the mobile requirements, to try to apply to >>> all touch environments, we have a problem, because many on Windows >>> platforms, the main AT is not delivered with the platform, it is >>> purchased separated (ZoomText, JAWS, Read & Write Gold, etc...). >>> >> >> Narrator comes with Windows 8.1 / 10 by default. It's quite limited, but >> it is there...and on touchscreen laptop/tablet/2-in-1 devices, it allows >> for gesture-based navigation too. >> >> So how >>> do we characterize mainstream technology without forcing developers to >>> support the "D&P magic hand gesture translator" and every other Ma & Pop >>> AT out there. >>> >> >> WCAG's glossary https://www.w3.org/TR/WCAG20/#atdef already says that >> we're talking about *mainstream* user agents. It should likely also talk >> about *mainstream* assistive techologies (because in its current wording, >> it allows for Ma & Pop AT that runs in conjunction with a mainstream user >> agent, meaning that currently ALL SCs need to also cover the Ma & Pop >> scenario whether they like it or not? >> >> I think that's a discussion that warrants a much wider participation than >> just the mobile TF. It feels like WCAG itself lacks a definition of >> assistive technology >> >> Certainly the concept of *mainstream* AT that relies on standard >> platform/UA interfaces/APIs should be mentioned somewhere in the glossary. >> >> >> P >> -- >> Patrick H. Lauke >> >> www.splintered.co.uk | https://github.com/patrickhlauke >> http://flickr.com/photos/redux/ | http://redux.deviantart.com >> twitter: @patrick_h_lauke | skype: patrick_h_lauke >> >> >> >
Received on Friday, 15 July 2016 04:54:17 UTC