HTML Accessibility Task Force Teleconference

18 Dec 2014

See also: IRC log


Judy, Adrian_Roselli, ShaneM, LJWatson, +1.617.319.aaaa, MarkS, janina, chaals, Joanmarie_Diggs, Liam, paulc, IanPouncey, Plh, [IPcaller], leonie


<trackbot> Date: 18 December 2014

<trackbot> Sorry, chaals, I don't understand 'trackbot, wake up please'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<scribe> scribe: MarkS

alt note

CN: Any other business?

JS: Add a longdesc topic

CN: RE: ALT Note, there are some bugs filed.

SM: That's were we are right now

CN: Any other bugs out there?

JS: yes, I have a few

SM: me too

LQ: Timeline?

SM: Updated doc by end of january is realistic
... get bugs filed by jan 9 please

WishList: https://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Wishlist_for_HTML5.1

CN: 5.1 wish list. This is a tracking device. Prioritized by where the activity is. If you feel strongly about something, do work to push it along
... anything else anyone wants to see on this list?
... I've heard discussions about how to handle panels, accordions, carousels, etc.
... there has been discussions to spec these up in HTML
... Leonie has done some work
... right now it heavily relies on ARIA and interop is problematic


MS: This is a very difficult thing to implement interoperable. Would like to discuss possible solutions further

CN: I will put in wiki

Keyboard access - https://www.w3.org/WAI/PF/HTML/wiki/Accesskey

CN: s/interoperable/interoperably

s/CN: s/interoperably/interoperably/

CN: link to use cases and requirements in the wiki. what we are trying to achieve
... accesskey is the motivating problem, has potential to clear up other lingering issues, tabindex, semantic elements with builtin interactions.
... should we be working on this in isolation, or as a greater interaction issue
... I would like to keep it simple, but we need to consider how any changes made in this space affect other interaction pieces of HTML
... has anyone looked at these use cases lastly?

LW: I have

LQ: me too
... think its worth looking into what HTML and browser people think about keybindings
... just to see if it would be productive to work on interaction as a whole

CN: at yandex, we are thinking about this a lot. we would like it to be better in our browser and in our services. considering whether working with access key as it is is better than nothing...

LW: I think its very broken as it stands.

CN: Paul, is the IE team interested in working on this problem at all?

PC is not santa claus

PC: I think you should ask cynthia about that

CN: I've been keeping the wiki page up to date. There are a list of bugs.
... what happens if you have an accesskey on a random element? how does it affect role? not at all.
...23612: script in there has an example of who should inform who
... think we should be changing that.
...27654: the user should be in charge of what keys are available to use as access keys
... provides an algorithm for UA to select available keys
... I agree that the user should have some control over this
... next bug, privacy. Can increase the accuracy of fingerprinting users. Reveals too much info about who you are and track you
... still not clear why we have accesskey label anyway. especially if the page shouldn't be telling the user how their browser should work
... wonders if the screenreader would rely on the DOM or the AAPI in this case

JD: Orca does everything through the AAPI, which gets most of its info from the DOM...
... could expose this info without it being in the DOM, like with CSS generated content

CN: and that is the common approach, correct?

JD: that is my understanding, but I don't know about JAWS and other windows Screenreaders

CN: Still work to do on this topic.

JS: Here's a crazy idea. I get nervous about anything keyboard centric since we are seeing more touch and voice interaction
... if we are saying that the user supplies the keys, were not just talking about a standard web page, its pages the user uses frequently, like an app, where users would take advantage of such a shortcut.
... perhaps we leave it entirely up to the user, that they can add their own shortcuts to any focusable content

CN: the activation behavior, may be a gesture rather than a key, could also be a voice command. We need to be very careful. At the bottom of the page, there is a statement that hints at this.
... can't just be a single key
... need to support various interactions
... agree that pages you are not likely to visit often, user won't hunt around for accesskeys. The approach of allowing the user to create their own bookmarks/shortcuts would be a UA feature, nothing to do with HTML

JS: I wonder if we made the automatic enumeration of elements, like Lynx did, you could port your shortcuts across environments

CN: like XPointer, but not something you would put in HTML spec.

<Zakim> chaals, you wanted to shoot you down (not really…)

<Zakim> liam, you wanted to support/ask-about more user control of access keys, e.g. rebinding

LQ: the web annotations working group is facing the problem of how to annotate a piece of the document. Associating text with a particular part of the page could be extending to supporting shortcuts
... To what extent is user control of accesskeys available? Can you override them?

CN: only through extensions at this point, i believe.
... support for access keys in general is poor to terrible.
... Opera mini probably has the best implementation of allowing users to overwrite

PLH: I wanted to agree with chaals, this is about getting the config from one UA to another. As soon as you start talking about making the config portable, its not within the realm of HTML
... nice to have, I agree, but outside of HTML scope.

<liam> [Liam wonders where plh feels such a conversation _could_ occur (agree not HTML spec) ]

<plh> [sure, but don't we have a long list of things to tackle for HTML?]

CN: think we should look into a way of revealing what executable things are in the page and can they have an identifier. No JS API currently.
... would be helpful to expose what executable things are in the page and can they have an identifier

JS: I like that idea a lot. I can see a l lot of applications that could benefit from that.

CN: is the obvious way to do this writing an extension spec, or file bugs on HTML? Paul?

JB: I would think that the end goal would be to integrate solution into the HTML spec. Potentially extension spec for development, but path back into HTML
... consider tapping into tabindex at the same time

<paulc> I suggest you talk to Robin about making the accesskey part of HTML5 (and other items like tabindex) into a "After HTML5" module so that it can be worked on following his new development methodology.

JB: don't think a lot of incremental bugs is the most useful path. anyone else?

PC: I suggest talking to Robin about turning this topic into a module that people can start working on.
... get it into github so people can start contributing and commenting

PLH: Should work it as a module, with possible integration later on. Agree that module is good idea and talking to robin

<paulc> The module should probably include some part of http://www.w3.org/html/wg/drafts/html/CR/editing.html#assigning-keyboard-shortcuts

<chaals> ACTION: chaals to talk torobin about an accesskey (maybe etc) module for HTML [recorded in http://www.w3.org/2014/12/18-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-294 - Talk torobin about an accesskey (maybe etc) module for html [on Charles McCathie Nevile - due 2014-12-25].

First meeting of 2015: date?

CN: this is last meeting for 2014. What date should we resume in 2015?

<plh> january 8?

<paulc> Thu Jan 8 would be the likely candidate for next meeting.

<ShaneM> +1

<paulc> Jan 1 is obvious the first Thu and is NOT a candidate.

<aardrian> +1


<Judy> +1

<paulc> Jan 8 +1

CN: January the 8th will be next meeting then

<chaals> RESOLUTION: next meeting january 8th

Any other business?

longdesc question

CN: longdesc, Janina?

<chaals> janina?

PLH: I think MIT is experiencing network issues
... anyone dialing in over IP will likely have issues

<paulc> Happy Holidays to everyone.

JB: Reminder for those from Member orgs to comment on PR with regards to longdesc. Janina had a question, but since she is not here...
... I propose we end the call

LW: Chaals just messaged us that he would like to thank everyone for the last 12 months of work and to have a happy holiday

Summary of Action Items

[NEW] ACTION: chaals to talk torobin about an accesskey (maybe etc) module for HTML [recorded in http://www.w3.org/2014/12/18-html-a11y-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014-12-18 16:51:43 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/CN: s/interoperable/interoperably/
Succeeded: s/interoperable/interoperably/
Succeeded: s/clause/claus/
Succeeded: s/example,/example of who should inform who/
Succeeded: s/ORCA/Orca/
Succeeded: s/the shortcuts are/executable things are in the page and can they have an identifier/
Succeeded: s/the shortcuts are/executable things are in the page and can they have an identifier/
Succeeded: s/Extension spec/Potentially extension spec/
Found Scribe: MarkS
Inferring ScribeNick: MarkS
Default Present: Judy, Adrian_Roselli, ShaneM, LJWatson, +1.617.319.aaaa, MarkS, janina, chaals, Joanmarie_Diggs, Liam, paulc, IanPouncey, Plh, [IPcaller], leonie
Present: Judy Adrian_Roselli ShaneM LJWatson +1.617.319.aaaa MarkS janina chaals Joanmarie_Diggs Liam paulc IanPouncey Plh [IPcaller] leonie

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 18 Dec 2014
Guessing minutes URL: http://www.w3.org/2014/12/18-html-a11y-minutes.html
People with action items: chaals

[End of scribe.perl diagnostic output]