RE: Updated accesskey.next material

It is the @key attribute that I continue to grapple with Shane - it opens up a whole slew of practical issues around discoverability, lack of standardization, error recovery questions, etc.  I will continue to maintain that done properly, a hotkey function would declare the 'hook' but that the key-mapping remains completely in the hands of the end user. While I have come to begrudgingly accept that currently a key-binding hint *may* have some value, my support there remains tepid due to other related issues, such as i18n and alternate keyboards (for example Chaals' Cyrillic keyboard at Yandex), and conflicts with AT key bindings, which are not standardized across different vendors .

 

A completely different, off-the-wall idea would be to create a linked document (similar to CSS) that could be used to do key-mapping/binding (in a fashion similar to how some sites/software do i18n messaging, by creating an array of "phrases" that are then dynamically inserted based on user language preference.) Again, the source code would provide the hook, but the key binding remains outside of the source-code, but linked, and can be modified or completely replaced by the end user (ala User Style Sheets, which I know get a bad rep now).

 

Backing up just a bit however, I think we should review the use-cases for in-page hotkeys first. It strikes me that any tab-focusable element is a primary candidate, along with the afore-mentioned landmark declarations (whether native - e.g. <nav> - or aria-roles), and *perhaps* headings (which screen reader users can already accomplish via their screen readers, but I could envision some sighted users wanting a similar function). Perhaps a linked document that allowed/declared mapping based upon document element IDs (?), or roles (?), or both (?).

 

 

> Finally, there is the question of activation.  I remember Judy indicating a concern
> about this.  In the Access Module we had an optional 'activate' attribute that defaulted
> to 'false' indicating that a targeted element would obtain focus, but would NOT be
> activated.  By setting activate to 'true' (or in HTML5 parlance, by just saying 'activate')
> you would be telling the useragent to move focus AND activate the element if it is
> capable of being activated.

 

(Polygot: activate="activate" :-)) - but good point and worth not losing sight of, as it is both "protective" but also expansive - there may indeed be a need for {focus+activate} in some web applications scenarios.

 

JF

 

 

From: ahby@aptest.com [mailto:ahby@aptest.com] On Behalf Of Shane McCarron
Sent: Thursday, November 20, 2014 1:14 PM
To: John Foliot
Cc: LWatson@paciellogroup.com; chaals@yandex-team.ru; HTML Accessibility Task Force
Subject: Re: Updated accesskey.next material

 

I like the idea of a declarative element like access that can bind to roles or ids - that way it is useful for arbitrary landmarks AND for specific items that an author might want to designate.

 

<access targetrole="someRole otherRole anotherRole" key="a b c..." />

 

would mean that they keys a or b or c would be used to nagivate to elements with a roles of someRole, otherRole, and anotherRole.  In the original Access Module we also defined an 'order' attribute so an author could designate whether the nagivation would be done in document order or "list" order, which meant the order as defined in the targetrole or targetid attributes.

 

The disadvantage of a declarative element is that it is (often) going to be separated from the element(s) it references in the document. But I think this disadvantage is far outweighed by the simplicity of a simple declaration rather than an @accesskey on each item in the document that might need a binding.

 

Finally, there is the question of activation.  I remember Judy indicating a concern about this.  In the Access Module we had an optional 'activate' attribute that defaulted to 'false' indicating that a targeted element would obtain focus, but would NOT be activated.  By setting activate to 'true' (or in HTML5 parlance, by just saying 'activate') you would be telling the useragent to move focus AND activate the element if it is capable of being activated.

 

Certainly it should be a requirement that the key mappings be locally definable / overrideable.  And, in the absence of @key, the user agent should probably assign a key or just put it in the pool of available items that *could* have a key and let users map it if they like.

 

Anyway, that's been my opinion for years, and I think it is still valid.

On Thursday, November 20, 2014, John Foliot <john@foliot.ca> wrote:

Léonie Watson wrote:
>
> It intuitively feels like there might be some overlap/connection into
> IndieUI with this. Not familiar enough with IndieUI to offer any more
> on that possibility though.

I agree with your intuition Léonie, which is why I still have a (perhaps
unreasonable) distaste for author-declared "keys".

Off the top of my head, I would likely prefer to see something like <access
role="navigation">, although if user-agents were smart, they wouldn't need
the access part: they could expose all of the landmark roles (or HTML5
landmark elements) into a "tree" that end users could map 'hotkeys' to
themselves (or swiping gestures, etc.). The advantage here of course is that
for *every* site that used <nav> or <div role="navigation">, if the
individual end user mapped that construct to their own keypress "shortcut"
(Alt+Shift+F2) it would *always* work across all sites, rather than trying
to learn or discover individual site-assigned keys.

I know Chaals argues that those author-assigned keys should (MUST?) be
re-mappable, but it still requires the "search if they exist in the first
place, and then do the remapping" exercise that I question the
usability/usefulness of. For infrequently visited sites, it doesn't seem
like the effort would be worthwhile, whereas if I could always invoke
Alt+Shift+F2 and it brough me to the page's declared navigation block, then
all of a sudden I have something reliable on my hands that I can use
"everywhere".

Another off-the-top thought: allowing to map hotkeys to any aria-role would
provide us with two potential wins:

a) it expands the ability to hot-key to anything, not just regions
(landmarks)
b) it expands the usefulness of the aria @role attributes, as designers who
may not be thinking first about accessibility could still use aria-roles to
achieve "mainstream" functionality, and we've often thought/stated that
making ARIA about more than just AT would be a positive thing. Rich S. told
me he had some success when he started to get some of the internal designers
at his shop to start using aria-roles as CSS selectors - they loved the idea
of repurposing an accessibility "thing" for something other than
accessibility, so there is a minor precedent there...


> Also wondering about use cases for other forms of interaction? For
> example the ability to move to the next/previous element/object - as is
> possible with the JavaScript driven shortcuts provided by Google/Gmail
> for example.
> Is this something a re-engineered accesskey could support?

http://www.w3.org/TR/html5/links.html#sequential-link-types

See also Bruce Lawson's now 5 year old blog post for some other
outside-the-box thinking (not 100% related, although he does 'diss'
accesskeys: http://www.brucelawson.co.uk/2009/rel-accessibility/

JF







-- 

Shane McCarron

Managing Director, Applied Testing and Technology, Inc.