Re: SC #62 Keyboard with AT (that remaps key input)

@Gregg: Yes and no.  For mobile in particular, the line between browser and
device/native capabilities is much closer together than on desktop.
Consumer demand for an "integrated" mobile experience is very high.  So
there is a tendency for OS manufacturers to provide capabilities you would
usually associate with a "native" experience, direct from the OS included
WebView implementation.  One of these capabilities is to interrupt/muck
with AT behavior.  The ability to effect AT and Keyboard events already
exists in Native and Hybrid apps on both major platforms (iOS and
Android).  This is forward thinking on both browser capability, and
potential encompassing of hybrid/native mobile apps under the WCAG umbrella.

@David: +1.  The thoughts here may indeed have a better "home" though I
thought that was already discussed somewhere...



On Tue, Jan 31, 2017 at 11:22 AM, Gregg C Vanderheiden <greggvan@umd.edu>
wrote:

> how is a web page designer going to have any effect on keyboards or AT
> behavior?
>
>
> They only can deal with the ‘keyboard input” that the web page receives
>  AFTER it comes in from the browser.    No?
>
>
> Gregg C Vanderheiden
> greggvan@umd.edu
>
>
>
> On Jan 31, 2017, at 6:05 AM, David MacDonald <david100@sympatico.ca>
> wrote:
>
> Hi Marc
>
> Here's the current language for #62
> ​.​
>
>
> Keyboard with AT (that remaps key input): All functions available by
> keyboard are still available by keyboard after accessibility-supported
> assistive technology that remaps keystrokes is turned on.
>
> In the comments for Issue #62, there appears to be emerging consensus that
> this is already required in 2.1.1. Accessibility support requires that
> Keyboard functionality still works when a screen reader is running. We've
> been failing content on that basis for years. However, what the new SC does
> point out, is that the Understanding document could be updated with a
> sentence about mobile, and that it also applies there. This is not a new
> requirement, so it doesn't need an SC, it just needs a bit of pastural
> guidance in the Understanding of 2.1.1.
>
> Cheers,
> David MacDonald
>
>
> *Can**Adapt* *Solutions Inc.*
> Tel:  613.235.4902 <(613)%20235-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 Mon, Jan 30, 2017 at 11:07 PM, Marc Johlic <marc.johlic@gmail.com>
> wrote:
>
>> Regrets for the same Austin meeting as Mike, Moe, and Lisa.   My two SCs
>> have good feedback - I will try to get pull requests in this week for them.
>>
>> On Fri, Jan 27, 2017 at 10:25 AM, Joshue O Connor <josh@interaccess.ie>
>> wrote:
>>
>>> The WCAG WG will be meeting on Tuesday, 31 January 2017 at 11AM Eastern
>>> US (Length: up to 90 minutes).
>>>
>>> Please reply with regrets to the list.
>>> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List
>>> IRC: irc.w3.org<http://irc.w3.org>  port: 6665 channel #wai-wcag
>>>
>>> Agenda:
>>>
>>> 1. Continued update from SC managers
>>> 2. SC for review by the group https://www.w3.org/2002/09/wbs
>>> /35422/SC_review_Jan2017/
>>> 3. AOB
>>>
>>> To connect to the meeting:
>>> Join WebEx meeting (https://mit.webex.com/mit/j.p
>>> hp?MTID=m064eab3e5485b640231a7fe56dc4785c)
>>> Meeting number:            642 418 206
>>> Meeting password:         Find in the irc meeting room header if you
>>> don’t know it
>>>
>>> or
>>>
>>> Join by phone
>>> +1-617-324-0000 <(617)%20324-0000> US Toll Number
>>> Access code: 642 418 206
>>> __
>>> Joshue O Connor | Director
>>> *InterAccess.ie <http://InterAccess.ie> - Accessible UX*
>>>
>>>
>>
>
>