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.