Re: FW: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)

I don't see that as an issue either.

Now, one thing we are going to run into with the people looking at
alternatives to accesskey is the ability to do the following:

   Allow the user to remap the shortcut in the browser
   Allow the user who is not using an AT to find the shortcuts

The ARIA task force cannot specify this functionality, as we have agreed to
not do so and because it is designed to be cross-cutting, but we could
suggest that a host language, supporting ARIA 1.1, do it. We are already
investigating using some ARIA 1.1 semantics in SVG to impact user agent
functionality.

Rich


Rich Schwerdtfeger



From:	Matthew King/Fishkill/IBM@IBMUS
To:	Dominic Mazzoni <dmazzoni@google.com>
Cc:	John Foliot <john.foliot@deque.com>, HTML Accessibility Task
            Force <public-html-a11y@w3.org>, public-pfwg@w3.org
Date:	06/10/2015 11:55 AM
Subject:	Re: FW: ACTION-1642: New aria-kbdshortcuts property (for Issue
            711)



> Dominic wrote:
> I agree about the concern about invisible controls, but I don't see
> a good alternative. If a control is invisible, it's not exposed to
> AT at all. If a web author wants a keyboard shortcut to be available
> even when its associated control is hidden, like a menu item, they
> should use CSS to hide the item in such a way that leaves it
> accessible to AT, such as by moving it offscreen or changing its z-index.

I would like to know if others are aware of any real and necessary use case
for controls visible to screen reader users and not others. A focusable
element off screen will cause focus indication to disappear, violating
WCAG. I have never seen a use case that justifies doing this and am pretty
confident that one does not exist.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:        Dominic Mazzoni <dmazzoni@google.com>
To:        John Foliot <john.foliot@deque.com>, HTML Accessibility Task
Force <public-html-a11y@w3.org>,
Cc:        public-pfwg@w3.org
Date:        06/10/2015 09:09 AM
Subject:        Re: FW: ACTION-1642: New aria-kbdshortcuts property (for
Issue 711)



Answers to questions raised by both Joseph and Stefan:

* The specified keyboard shortcut would activate a control, not focus it.
If it's a button, it implies that pressing that shortcut clicks on the
button.

* Adding this attribute to an element does not change any browser
behavior. Adding role=button to an element doesn't make it a button,
it just informs AT that it acts like a button. Similarly, adding
aria-kbdshortcuts to an element doesn't make those keyboard shortcuts
function, it just informs AT that those keyboard shortcuts are available.
It's up to the author to implement it.

* Discoverability: AT such as screen readers could now announce the
shortcut
for a button or menu item upon focusing it, just like when a user explores
a native menu item in a desktop app. It is still totally up to the author
how to expose this keyboard shortcut to non-AT users.

* Remember, lots of web sites *already* have keyboard shortcuts that
activate controls and menu items. This spec simply provides a consistent
way to provide this information to AT. Otherwise, authors have to include
this information in a control's label or description.

* Providing the keyboard shortcut in a standard format allows the AT to
not only expose it to the user, it allows the AT to parse it, transform it,
or act on it. For example, a screen reader could discover that a key
conflicts with a built-in key and *automatically* suggest using the
passthrough key. Or, other AT could let the user press one modifier key
and then highlight all commands that can be activated using that modifier.
These are not *primary* use cases, they are simply arguments in favor of
making this a standardized, parseable attribute as opposed to just free
text.

* How does this differ from accesskey? So many ways:

  - Accesskeys have different modifiers in every browser. See the Wikipedia
    page to get an idea of how confusing it is for web developers and
users:

    http://en.wikipedia.org/wiki/Access_key

  - Accesskeys don't even have the same *behavior* in all browsers - some
    just focus, others activate.

  - Accesskeys don't let you choose the modifier keys. Setting
    accesskey='h' means to press Alt+H in IE, there's no way to make
    a shortcut like Ctrl+H, Alt+Shift+H, or just 'H' with no modifier keys.

  - Web developers already have lots of other ways to support keyboard
    shortcuts in their web apps. Accesskeys are the only ones that are
    currently exposed to screen readers, but they're very limited, so web
    developers don't actually use them much. This proposal allows web
developers
    to *implement* keyboard access however they choose, and simply *expose*
    the information about those shortcuts to AT in a consistent way.

* If a control has both accesskey and aria-kbdshortcuts, I think
aria-kbdshortcuts should be the only one exposed to AT, just like
aria-label
overrides alt.

* I agree about the concern about invisible controls, but I don't see a
good alternative. If a control is invisible, it's not exposed to AT at all.
If a web author wants a keyboard shortcut to be available even when its
associated control is hidden, like a menu item, they should use CSS to
hide the item in such a way that leaves it accessible to AT, such as
by moving it offscreen or changing its z-index.


On Wed, Jun 10, 2015 at 9:03 AM John Foliot <john.foliot@deque.com> wrote:
Specifically copying the HTML-a11y TF, who may not always see PF-bound
emails.

Related to the @accesskey discussion underway. Coordination will be
critical
here, as the same open questions exist for both efforts (discoverability,
alternate mapping options, etc.) .

JF


> -----Original Message-----
> From: Joseph Scheuhammer [mailto:clown@alum.mit.edu]
> Sent: Wednesday, June 10, 2015 8:24 AM
> To: public-pfwg@w3.org
> Subject: Re: ACTION-1642: New aria-kbdshortcuts property (for Issue 711)
>
> > Please review this proposal based on a proposal from Dominic Mazzoni
> > for the Thursday ARIA call. We may come up for another name for this
> > ... like aria-shortcuts, aria-key, or aria-keygboardshortcuts:
>
> Some thoughts and questions:
>
> 1. Name: I suggest aria-hotkey.
>
> 2. Discoverability -- how do users find out what the key combinations
are?
>
> 3.  The spec text says that if the control is invisible, then its
keyboard
shortcut
> does not trigger the action.  This will exclude menu items within a menu
that is
> not popped open.  That is different from how menuitems work on the
desktop;
> for example, cmd+s on a Mac activates the "File" menu's "Save" menuitem
even
> when the menu and menuitem are invisible.
>
> 4. How do aria-kbdshortcuts apply in the case of touch interfaces?
>
> 5.  How does this differ from accesskey [1], i.e. what problem does it
solve that
> accesskey doesn't?  I think part of the answer is that aria-kbdshortcuts
includes
> the modifier keys, whereas acceskey doesn't, which is clearer.
>
> 6.  How does aria-kbdshortcuts interact with accesskey?  Which one wins
if
an
> element has both?
>
> [1]
> http://www.w3.org/html/wg/drafts/html/master/editing.html#assigned-
> access-key
>
> --
> ;;;;joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>             - G. Bernhardt -
>