See also: IRC log
<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
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
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
+1
MS: This is a very difficult thing to implement interoperable. Would like to discuss possible solutions further
CN: I will put in wiki
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].
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
+1
<Judy> +1
<paulc> Jan 8 +1
CN: January the 8th will be next meeting then
<chaals> RESOLUTION: next meeting january 8th
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
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]