- From: Léonie Watson <LWatson@PacielloGroup.com>
- Date: Thu, 20 Nov 2014 21:45:23 -0000
- To: "'John Foliot'" <john@foliot.ca>, <chaals@yandex-team.ru>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
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