HTML Accessibility Task Force Teleconference -- 20 Mar 2011

<trackbot> Date: 20 March 2011

<richardschwerdtfe> you be on mute? Ha!

<richardschwerdtfe> scribe: Rich

Video Examples with TTS control of audio descriptions

<richardschwerdtfe> First example: use ARIA live region

<richardschwerdtfe> Example renders extended description using TTS

<richardschwerdtfe> mkobyyas: We can change the speed of the audio description

<richardschwerdtfe> mkobyyas: Can also use TTS server

<richardschwerdtfe> mkobyyas: Sends text to server and returns audio

<richardschwerdtfe> eric: How do you synchronize this with the video?

<richardschwerdtfe> mkobayas: time update

<richardschwerdtfe> rich: Summary: Get text, send to server, get audio file, play it, wait for next timed text call

<richardschwerdtfe> sean: pause on exit seems like the wrong thing

<richardschwerdtfe> eric: he is correct.

<richardschwerdtfe> sylvia, can you show how it works?

Demo Sean Hays

<richardschwerdtfe> niet

<richardschwerdtfe> Sean: I created a script called trakks.js

<richardschwerdtfe> sean: I have three different tracks one for captions, two for descriptions

<richardschwerdtfe> Sean: That make you allowed to do the track markup

<richardschwerdtfe> Sean: the idea is that you can do other things. I have an Iframe pointing to the same TTML file that is styled as ...

<richardschwerdtfe> Sean: I am actually using the track API

<Sean_> http://www.cwmwenallt.com/access/player.html

<richardschwerdtfe> sean: This demo is on Safari

<richardschwerdtfe> sean: if I look at in FF or IE it looks the same

<richardschwerdtfe> sean: there are 4 levels of navigation in the file

<richardschwerdtfe> sean: if I drill down I can skip along ...

<richardschwerdtfe> sean: so I can skip along at the various levels

<richardschwerdtfe> sean: If I skip up a level then the section level changes

<richardschwerdtfe> sean: So, that is doing navigation based on the XML file

<oedipus> very nice tab navigation for the player with exposed text being spoken

<richardschwerdtfe> sean: so this is TTML turning up as captions

<oedipus> i'm testing with IE9

<richardschwerdtfe> sean: I turn on audio descriptions. So, rather than generating the audio. ...

<oedipus> hmm, can tab navigate the controls, but can't get them to activate

<richardschwerdtfe> sean: so, this is using the caption file as captions as well as descriptions. It also points to the audio files

<richardschwerdtfe> sean: the media tracks shows the signing

<richardschwerdtfe> sean: the signing is a separate video file that is synched

<richardschwerdtfe> sean: so I switched the source

<richardschwerdtfe> silvia: so it is burned in

<richardschwerdtfe> sean: yes

<richardschwerdtfe> sean: the access to the pixels does not work on all the browsers

<richardschwerdtfe> eric: do you support alpha in 2.64

<richardschwerdtfe> frank: no

<richardschwerdtfe> eric: do you support ping - a compression format

<richardschwerdtfe> frank: no

<richardschwerdtfe> sean: new demo

<richardschwerdtfe> sean: I can import an scc file

<richardschwerdtfe> sean: now that I can support that fxp file ...

<richardschwerdtfe> secan: In this one the dfxpis transparent

<richardschwerdtfe> thanks

<richardschwerdtfe> silvia: how much of the dfxp have you implemented

<richardschwerdtfe> sean: all of it except for the obscure timing stuff

<richardschwerdtfe> sean: If I edit the .dfxp file ...

<richardschwerdtfe> nobody speaking just now

<richardschwerdtfe> sean: the styles in here map to CSS files

<richardschwerdtfe> silvia: so you can also do bold and italic:

<richardschwerdtfe> sean: yes. all of the classes get mapped to class Q

<richardschwerdtfe> sean: you can overwrite them can't you

<richardschwerdtfe> silvia: you implement to different regions - one for the speaker

<richardschwerdtfe> sorry: sean: you implement to different regions - one for the speaker

<oedipus> style sheet for sean's demo: http://www.cwmwenallt.com/access/style/jquery-ui-1.8.9.custom.css

<richardschwerdtfe> sean: so there the top region is separate from the bottom one.

<richardschwerdtfe> sean: two different navigation regions. keyboard navigable

<richardschwerdtfe> sean: I tested with NVDA and both get working.

<richardschwerdtfe> sean: I tried aria-live but does not work across all browser

<oedipus> can access UI with IE9, but can't play (to be expected, no?)

<richardschwerdtfe> sean: If I were using the TTS engine you could simply send the text and generate the audio on the fly

<richardschwerdtfe> sean: I did not find out about the bing translator until just now. I might have a go at that

<oedipus> what is the bing translator?

<richardschwerdtfe> converts text to audio (server based)

<oedipus> found it: http://www.microsofttranslator.com/

<richardschwerdtfe> sean: I will try to find a link to that

<richardschwerdtfe> there

<richardschwerdtfe> Demo: Silvia

<oedipus> http://blogs.msdn.com/b/translation/

<richardschwerdtfe> silvia: so this is a build of Chromium which is a build of webkit code

Silvia Demo on chromium

<richardschwerdtfe> silvia: this is a build by one of the people in Google (not myself) doing text track on chromium

<richardschwerdtfe> silvia: it is implemented in the browser

<richardschwerdtfe> silvia: it's been built into the framework of how video works

<richardschwerdtfe> eric: so what she has done is add a generic track element to webkit and a number of classes to read the data from the track to decode it. The whole thing is done in a very generic way and it is not a big deal to put in a generic parser

<richardschwerdtfe> eric: it was done as a text track. Binaries would be more work. Basic plumbing is in webkit 4

<richardschwerdtfe> eric: we just got code from the person doing this on Friday

<richardschwerdtfe> eric: it is a simple matter of finishing this on Safari

<richardschwerdtfe> silvia: there is a lot more to do

<richardschwerdtfe> silvia: we are on the way and we are getting there. It fits with the other stuff in video. That basically states what we have designed so far can be implemented.

<richardschwerdtfe> sean: the styling you had on that caption, where did that come from ... so you are not hooked up to the CSS

<richardschwerdtfe> silvia: this is a very, very early pre-release thing but the first thing is done

<richardschwerdtfe> mike: is the build available publicly

<richardschwerdtfe> silvia: no

<richardschwerdtfe> eric: I am working with her but she is a new webkit contributor. The plan is to get it into shape to get it into the tree

<richardschwerdtfe> eric: the point is it will be in there to play around with

<richardschwerdtfe> frank: what was the trickiest thing to implement so far?

<richardschwerdtfe> eric: the architecture

<richardschwerdtfe> silvia: one thing to note the styling ...

<richardschwerdtfe> eric: it is done with an element in the shadow dom

<richardschwerdtfe> frank: we are considering doing a similar thing

<richardschwerdtfe> silvia: how do you do the controls?

<richardschwerdtfe> frank: custom draw them

<richardschwerdtfe> silvia: cool

<richardschwerdtfe> eric: hooking this up to CSS is no work at all as it is in the shadow DOM. ... hours of work

<richardschwerdtfe> eric: Since Webkit is open source. We have to get the architecture and the code submitted. I don't know how far off it is. It will take a week or so to get it all checked in. As it is an early draft it will take 3-5 weeks

<richardschwerdtfe> silvia: I would say at least a month. soonish

<richardschwerdtfe> silvia: the spacial markup for WebVTT

<richardschwerdtfe> silvia: deciding if to use generic HTML markup in queues

<richardschwerdtfe> frank: we would like that. CSS ...

<richardschwerdtfe> silvia: pseudo selector support to get to the shadow DOM

<richardschwerdtfe> Mike: running a little bit over. The next thing we want to do is do a review of yesterday's minutes

<MikeSmith> http://www.w3.org/2011/03/19-media-minutes.html

review media minutes

<richardschwerdtfe> MichaelC: Review issue 147 and talk about drag and drop

<MikeSmith> minutes of media subteam breakout from March 19

<richardschwerdtfe> MichaelC: the minutes are by date

<richardschwerdtfe> Mike: Issue 147

Issue 147

<MikeSmith> http://dev.w3.org/html5/status/issue-status.html

<richardschwerdtfe> Mike: this is the playback rate thing

<JF> Issue 147 http://www.w3.org/html/wg/tracker/issues/147

<richardschwerdtfe> silvia: frank did you put that in ?

<richardschwerdtfe> frank: yes

<richardschwerdtfe> frank: It seems prudent that you know where you are in live streaming such as if you are behind. It also seems prudent to tell the author if there are issues with playing back at a certain rate.

<richardschwerdtfe> frank: we want to have something that does not change and ship what we have today in the spec.

<richardschwerdtfe> silvia: the playback rate tells you the rate it is playing back. If playing backwards it is negative. That is what playback rate does and you can adjust it in JavaScript

<richardschwerdtfe> eric: this is a javascript API. The text in the spec. says the user sets it and the browser plays it

<richardschwerdtfe> mike: where we are at is we have a bug and Hixie says won't fix.

<richardschwerdtfe> mike: we are going to adopt this unless someone introduces a counter proposal

<richardschwerdtfe> silvia: it is overloaded as the browser can tell you what it has done.

<richardschwerdtfe> silvia: I introduced a change proposal

<richardschwerdtfe> mike: the next thing to do is put out a survey

<richardschwerdtfe> mike: the bug triage team said this does not have any relation to accessiblity concerns

<richardschwerdtfe> silvia: I would think Janina might be concerned about a playback rate

<richardschwerdtfe> eric: the spec. tells you play at the rate the browser told to play

<richardschwerdtfe> eric: Hixie says if the browser can't perform it sucks

<richardschwerdtfe> janina: my mother who is not a native English speaker so she would want to see things slown down

<richardschwerdtfe> sean: it is a mainstream thing too

<richardschwerdtfe> silvia: Ian regards the playback rate as a vehicle to tell the browser what to do

<richardschwerdtfe> silvia: he thinks the browser's ability to convey what it was able to do would be good.

<richardschwerdtfe> silvia: Ian wants to see the reporting

<richardschwerdtfe> silvia: Hixie did not like my proposal

<richardschwerdtfe> silvia: there is a whole discussion on statistics but there is no concrete proposal on the table yet and I would like to pull what was said together

<richardschwerdtfe> silvia: Hixie wants us to assemble all the statistics

<richardschwerdtfe> eric: Phillip said adding an attribute for the actual rate is insufficient

<richardschwerdtfe> eric: what is implemented in Webkit is a script that tells us to change the rate and a signal is generated when the rate has changec

<richardschwerdtfe> eric: leave it the way it is

<richardschwerdtfe> mike: from the task forces perspective we need to decide to whether to endorse a specific proposal

<richardschwerdtfe> janina: we should discuss at the next telecon

<Sean_> link to Bing translator http://msdn.microsoft.com/en-us/library/ff512404.aspx

<richardschwerdtfe> thanks Sean

<MikeSmith> ACTION: Michael(tm) to add an agenda item for next week's telcon for discussion of issue 147 [recorded in http://www.w3.org/2011/03/20-html-a11y-minutes.html#action01]

<trackbot> Sorry, couldn't find user - Michael(tm)

<MikeSmith> ACTION: Mike to add an agenda item for next week's telcon for discussion of issue 147 [recorded in http://www.w3.org/2011/03/20-html-a11y-minutes.html#action02]

<trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.

<trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.

<richardschwerdtfe> Mike: we wanted to do summaries of yesterdays discussions

<MikeSmith> http://www.w3.org/2011/03/19-html-a11y-minutes.html

<richardschwerdtfe> Mike: we talked about text alternatives a bit

<richardschwerdtfe> Mike: Laura is not in complete agreement with those in the task force

<richardschwerdtfe> Mike: Cynthia did you have the discussion on text alternatives

<richardschwerdtfe> Cynthia: Steve was supposed to send a draft last night but I did not get one

<richardschwerdtfe> Mike: We saw an Opera plug-in that makes longdesc discoverable

<richardschwerdtfe> John: there was a jquery plug-in

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

<richardschwerdtfe> Mike: that is new info

<richardschwerdtfe> Mike: you took an action item to fold that into the change proposal

<oedipus> http://www.d.umn.edu/~lcarlson/research/ld.html

<richardschwerdtfe> John: Steve Faulkner also provided draft text

<JF> http://www.html5accessibility.com/tests/img-longdesc.html#long

<oedipus> HTML WG Bug 10853: HTML5 lacks a verbose description mechanism http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

<richardschwerdtfe> mike: the summary on longdesc is we made some progress on long desc. and we got wider support of retaining longdesc

<richardschwerdtfe> Mike: ARIA lexical processing

<oedipus> http://www.w3.org/2011/03/19-html-a11y-minutes.html#item03

<oedipus> http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria

<MikeSmith> richardschwerdtfe: we need a means to detect clickable regions…

<MikeSmith> … so that authors can assign events to regions

<oedipus> http://www.html5accessibility.com/tests/aria-changes.html

<MikeSmith> … gives you the bounding rectangle

<MikeSmith> … satisfies an authoring need

<MikeSmith> … ties input back to the actual DOM

<MikeSmith> http://dev.w3.org/html5/status/issue-status.html

<richardschwerdtfe> Mike: The last open issues

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection

<richardschwerdtfe> MikeSmith: we are good to go on the relevant accessibility issues

<richardschwerdtfe> MikeSmith: We will talk about drag and drop

<oedipus> http://dev.w3.org/html5/spec/dnd.html#dnd

<richardschwerdtfe> MikeSmith: summaries?

<MikeSmith> http://www.w3.org/2011/03/19-media-minutes.html

<richardschwerdtfe> silvia: need Mark Watson but is not around

<richardschwerdtfe> silvia: don't think they know how to dial in

<richardschwerdtfe> silvia: As a summary we started out with the use cases (3). In band tracks

<richardschwerdtfe> silvia: One resource mentioned int the source attribute of the video element

<richardschwerdtfe> silivia: we have external tracks as slaves to the main track

<richardschwerdtfe> silivia: we have equivalent video elements that are synchronized

<richardschwerdtfe> silvia: we need support for the second one with the slaved timeline. This will be very important for sign languages video and audio descriptions

<richardschwerdtfe> silvia: that was the key agreement on which we based the design work

<silvia> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API#.2810.29_HTML_Accessibility_Task_Force_proposal_.28.22The_San_Diego_Solution.22.29

<richardschwerdtfe> silivia: this is option 10 on our wiki page

<richardschwerdtfe> silvia: we focused on our first use case - inband tracks

<richardschwerdtfe> silvia: on our agenda we are a little bit behind but we are making good progress

<silvia> http://lists.w3.org/Archives/Public/public-html-a11y/2011Mar/0131.html

<richardschwerdtfe> silvia: we just did the JavaScript API. We don't believe that needs more work

<richardschwerdtfe> silvia: we need to look into rendering and CSS

<richardschwerdtfe> silvia: I think we can finish this today but not far beyond that

<Zakim> oedipus, you wanted to say we still have a LOT of outstanding issues with TABLE markup and algorithms (what wendy was working on)

<oedipus> we should, at least, review/re-assign outstanding TABLE issues while we are in plenary session -- i have summary as element http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element

<richardschwerdtfe> gregory: we have issues with table that have not been addressed in months

<richardschwerdtfe> gregory: we should review or reassign these issues

<richardschwerdtfe> cynthia: we had not decided to address this as last call

<JF> +q

<richardschwerdtfe> janina: we have summary and longdesc to come back to.

<richardschwerdtfe> JF: there was a resolution to keep as HTML 4

<JF> http://www.w3.org/2002/09/wbs/40318/issue-32-objection-poll/

<richardschwerdtfe> MikeSmith: I had a question about the track element

<oedipus> silvia, http://www.w3.org/2011/03/19-media-minutes.html

<silvia> oedipus, thanks!

<richardschwerdtfe> MikeSmith: Hixie's position is to limit eternal timed text formats but others are not satisfied with that. Hixie will need to be flexible

<richardschwerdtfe> eric: we will have a proposal tomorrow

<richardschwerdtfe> silvia: yes

<richardschwerdtfe> Mike: what do you need form Mark Watson?

<richardschwerdtfe> eric: I don't think he will have an issue but Mozilla might

<richardschwerdtfe> eric: Mozilla may supply a separate change proposal

<richardschwerdtfe> Silvia: Ian will supply a change proposal

<richardschwerdtfe> silvia: we may get another 3 change proposals by Tuesday

<richardschwerdtfe> eric: it is a very complex issue

<richardschwerdtfe> silvia: it needs a lot more discussion

<richardschwerdtfe> MikeSmith: we just need to get things submitted on time

<oedipus> http://dev.w3.org/html5/spec/dnd.html

Drag and Drop in HTML5

<richardschwerdtfe> MikeSmith: Status on drag and drop

<richardschwerdtfe> MikeSmith: the deal with drag and drop is it has been kind of an open discussion. However Hixie made significant changes to the spec. by introducing a dropzone

<MikeSmith> http://lists.w3.org/Archives/Public/public-html-a11y/2011Jan/0298.html

<oedipus> http://dev.w3.org/html5/spec/dnd.html#the-dropzone-attribute

<richardschwerdtfe> MikeSmith: Gez reviewed but the issue of keyboard accessibility is resolved.

<oedipus> http://dev.w3.org/html5/spec/dnd.html#the-dragevent-interface

<richardschwerdtfe> MikeSmith: Rich wants to view conflicts with ARIA.

<richardschwerdtfe> Rich: I will reopen after a review

<oedipus> "All HTML elements may have the dropzone content attribute set. When specified, its value must be an unordered set of unique space-separated tokens that are ASCII case-insensitive. The allowed values are the following:"

<oedipus> "copy: Indicates that dropping an accepted item on the element will result in a copy of the dragged data."

<oedipus> "move: Indicates that dropping an accepted item on the element will result in the dragged data being moved to the new location."

<oedipus> "link: Indicates that dropping an accepted item on the element will result in a link to the original data

<richardschwerdtfe> MikeSmith: we had a break scheduled at 10:30

<richardschwerdtfe> Judy: I think it was back at 10:03 your time I saw Rich Schwerdtfeger minute that Laura was not in full agreement with the task force discussion on the taskforce discussion on longdesc, but in the communication i saw, she said it looked like the group made good progress.

<richardschwerdtfe> Judy: it looks like she further tweeked her proposal on longdesc.

<MikeSmith> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformaceChoices

<richardschwerdtfe> Mike: I think it is fair to say the position she has taken on the change proposals is such that the issue is relative to text alternatives

<richardschwerdtfe> Judy: In looking back I see that. ok

<richardschwerdtfe> Janina: she created change proposals for other people's positions

<richardschwerdtfe> Janina: it may be attributed to other items such as longdesc

<oedipus> Issue 122 change proposal drafted by GJR in fulfillment of an action item assigned at HTML WG F2F at TPAC 2010: http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

<richardschwerdtfe> MikeSmith: it would be good to get Laura on a phone call

<richardschwerdtfe> Judy: has a family issue at the moment

<oedipus> GJR has action from TF yesterday to reply to survey on ISSUE 122 on behalf of TF -- circulated proposed comment to facillitators and staff

<richardschwerdtfe> Judy: I am also trying to get more coordination. So, probably won't happen this weekend

<richardschwerdtfe> MikeSmith: I think we can get the issue addressed very quickly if addressed in real time

<MikeSmith> big thanks to Rich for scribing

<richardschwerdtfe> yw

<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2011-03

ARIA Integration

<MikeSmith> scribe: MikeSmith

richardschwerdtfe: as far as I know, about ARIA integration, we are waiting for the edits

MichaelC: we wanted to talk about the mapping document

cyns: we need more people helping on this

<MichaelC> HTML API mapping document

richardschwerdtfe: yeah

Steve: I have started to work on it again
... two big tables in this doc

… pretty much done, but so far with input only for a couple people

… so it obviously needs scrutiny

<oedipus> http://dev.w3.org/html5/html-api-map/overview.html#api-role

<oedipus> http://dev.w3.org/html5/html-api-map/overview.html#api-att

cyns: when I generated the original table, I did it based on looking at existing browsers

richardschwerdtfe: do you have events in here?

<oedipus> note: there is a relatively new version of IA2 at http://a11y.org/ia2-spec

Steve: I looked at placeholder, and how it's being mapped

… looking at how the accessible name is handled

Steve: there are differences between how Firefox and Webkit implement this
... the way that placeholder vs title is handled in some browsers does not seem right

<oedipus> http://dev.w3.org/html5/html-api-map/overview.html#calc

cyns: I'm not sure that wrapping it around is per spec

MichaelC: it is, though not recommended

cyns: there are a lot of cases where people don't put labels on selects

Steve: there is a need for this document, because browsers are not handling it interoperably
... I've been talking with Alex Surkov

… and he has claimed that the FF is right per the ARIA name calculations

MichaelC: it does include some HTML rules, but…

cyns: it says, "title always loses"

MichaelC: and placeholder is not in the ARIA spec, because we were working from HTML4

<oedipus> ;)

Steve: you can see that there are still lots of TODOs in this document still

… you can see I started to work on the description of how to handle the summary and details elements

cyns: we need to finish the ARIA implementors' guide

… discuss with David Bolter, others

Steve: the idea is to get some stuff into the document even if it's not all been agreed on yet, so that we have something to start with

<oedipus> http://www.w3.org/WAI/PF/aria-implementation/

Steve: e.g., the summary element should be a button role
... details and summary are being implemented now

… Chrome has an implementation

… and there are JS implementations of this

… one thing we need to look at is, it seems more logical to have the open/closed state on on the actual summary

cyns: but buttons don't have that

Steve: all of the action occurs on the disclosure widget itself

cyns: do you have range and menu and command?

Steve: feel free to edit :)

cyns: I need to get my CVS access working

MikeSmith: I can help with that at lunchtime

Steve: do we need a role=video?

cyns: could just do it as a landmark

richardschwerdtfe: do you have a control pattern?

<oedipus> role=video makes sense, and has precedent: role=math

cyns: don't think we have one in UAG yet
... I think it could be confusing for people if we end up duplicating information from the ARIA implementor's guide?

Steve: maybe we should have an ARIA+HTML guide

cyns: actually, we went to a lot of trouble to make the ARIA implementor's guide to be language-agnostic
... we need to tread carefully to avoid redundancy
... great work on this so far, Steven

<oedipus> plus one: great work SteveF

richardschwerdtfe: yeah, and we still need to address canvas handling

Steve: yeah, there is obviously overlap, and we need to resolve that

richardschwerdtfe: PF really needs to review UAG

<oedipus> http://www.w3.org/WAI/PF/aria-implementation/

<oedipus> cyns, do you want the UAWG to review http://www.w3.org/WAI/PF/aria-implementation/

cyns: sorry, yeah, I'm talking about the ARIA implementation guide

<oedipus> ARIA comments have public view and all of the ARIA editors' drafts are public

<cyns> scribe: cyns

keyboard access

cyns: what about keyboard access?

<oedipus> having infrastructural problems please standby

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

<oedipus> how is user to decide what accesskeys to use: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10775 status: the HTML Accessibility Task Force needs to review the following quotes from the 18 March 2011 Editor's Draft which follow to ensure that this bug has been adequately addressed; of pariticular concern is that there is no stipulation that when a UA or user chooses a set of accesskeys, that...

<oedipus> ...that set of accesskeys will be uniformly applied (no mixing of accesskey strings: once a set of accesskeys is chosen, the user agent must them limit the accesskey values to those that match the position of the initially chosen accesskey)

GR: bug 10775. you can have a space-delimited list of accesskeys. how can user figure out what to use.
... my proposal was to make that a cascade.
... what's currently in the spec is examples that use multiple access keys. There's nothing in the spec that says which to use
... Say I have a search field. accesskey="S 0". you can get that accesskey by typing alt+S or alt+0, but if you have each accesskey assigned more than one value, that you have a cascade.
... so if you have S used somewhere else, it would fall back to 0. Otherwise, you can only use S, not both
... how do you get to that second key of accesskeys.

MS: Ian says that you don't expose those to users. UA makes the selection, and only exposes the selected key to the user. multiple values are not exposed to the user.

GR: i have an inherent distrust of UA chosing for me. I want to choose if I want to use alpha or other user accesskeys

MS: so bug should say that if there are multiple accekeys exposed to the user, so the user can choose. The current spec assumes that's not something users need. Need to provide a use case.
... looking at the status on this, hixie moved it to rejected, but you commented, then hixie made a spec change, to add informative text to give an explaination and posted a dif, bug triage said in January that the change addressed the original issue.
... if that's not the case, you need to re-open the bug or make a new one.

GR: I guess I do.

MS: new bug should challenge assumption in the spec that users don't need to have the full list of accesskeys exposed to the user.

GR: discoverability is a problem. author proposes user disposes.

MS: create a use case.

GR: what hixie wrote is very nebulous. UA will decide what to do based on capabilities of device.
... UA might pic numberic keyboard on a phone or alpha on a full keyboard. User should be able choose.

CS: would configurability be enough? could make for very complex UI

GR: how many accesskeys are likely?

MS: this is a problem in earlier versions of HTML
... previous spec for accesskey only allowed one value, right?

GR: right

MS: there were other ways, such as through scripting

CS: sort of. not declaratively

MS: previous spec was less precise on what UA behavior should be.

GR: right. so if we're paving the cow path, let's do a good job. make sure that it's discoverable.

MS: frame the discusision instead as... great, now we have a standard way to define multiple access keys, and now we need to refine that for the case where someone might want to choose which key
... better to close this bug, and create a new one that refines the behavior

RS: is teh behaivor on a non-alpha keybaord defined?

CS: yes.

RS: so waht is that you are looking for?

GR: user should be able to choose whether they want the first token for every value, second token, etc.

MS: this is a bigger issue, or needs to be framed differently. describe the use case and go from there. you don't have anything in the use case. need to explain why the user wants to do this

GR: ok

<oedipus> HTML WG Bug 10773 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10773 - accesskey should chosen from document's declared charset marked RESOLVED WONTFIX status: the HTML A11y TF must decide if this is an important point of clarification; this reviewer thinks it is and needs to be added to the current text

GR: accesskey should be chosen from documents declared character set. for example, if I'm using a doc that's english, I shouldn't have a character that's not english

CS: aren't most web pages UTF-8 now?

MS: no, lots of Japanese and Korean are not
... TF bug team thought Ian's fix was ok

GR: don't agree

MS: write an email to TF to discuss, put on telecon agenda.

GR: I will prepare 2-3 a week to work thoruhg

MC: TF bug team may have said that because we thought the whole team doesn't need to be invovled. Gregory can do it himslef.

MS: Need use cases.

GR: I will bring them to task force, and they can decide if we will address it or if Gregory should do it on his own.

MS: TF may need to work on that. Bring use cases, and what should change.

breaking for lunch

<oedipus> ok, thaniks

<MikeSmith> janina_lurker: big thanks to Microsoft and to Cynthia in particular for sponsoring the meeting

<MikeSmith> the non-media breakout folks are now adjourned

<MichaelC> s/ok, thaniks//

- DRAFT -

HTML Accessibility Task Force Teleconference

20 Mar 2011

Attendees

Contents