RE: Updated accesskey.next material

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

I don't think any thoughts right now are unreasonable :)

The thing I like about author defined suggestions is that they're likely to
be suited to the website/application, and therefore (probably) easier for
people to learn. The counterpoint is the likelihood of the author defined
suggestions remaining active, given the conflict resolution chain.

"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."

Those would both be good things to achieve. I'm not sure it solves the same
thing that accesskey could/should though?

I think the appeal of accesskey is that it allows someone to target a
particular instance of an element, not every instance of that element within
the UI. Screen readers already have the capability to do much of what you
suggest (which is very useful), but they come up against the same problem.
It still takes time to locate the link/field/whatever you're after from a
list of all links/fields/whatevers in the UI.

Léonie

-- 
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup


-----Original Message-----
From: John Foliot [mailto:john@foliot.ca] 
Sent: 20 November 2014 20:01
To: LWatson@PacielloGroup.com; chaals@yandex-team.ru; 'HTML Accessibility
Task Force'
Subject: RE: Updated accesskey.next material

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, 
Alt+Shift+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

Received on Thursday, 20 November 2014 21:45:42 UTC