13 Nov 2014

See also: IRC log


Chaals McCathie Nevile
Léonie Watson


<janina> akim, ??P14 is me

<scribe> scribe: Léonie Watson


CMN: We're essentially done.

PC: Nothing the TF needs to do. Transition request went to the chairs, PLH is scheduling a meeting with the Director.

JB: There are schedule complications. It may not be possible to do everything before Thanksgiving.

JS: Expect more use cases for longdesc to come from the Digital Publishing Group.


CMN: We're going through the process, but don't think there is anything else we need to do?

<MarkS> Bug 27263 - addHitRegion should inform the user of the new location for the fallback element based on the associated hit region -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27263

MS: Filed a couple of bugs.

<MarkS> Bug 27264 - Scrolling behaviour is too prescriptive. Should follow behaviour of other focusable elements. -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27264

s/Media Publishing/Digital Publishing/

MS: The TF is meeting tomorrow to discuss.

PC: If the TF meeting tomorrow? Sam is in transit, and didn't think there needed to be a meeting until the bugs have been dealt with.

MS: Ok, was working on the assumption that we didn't meet last week so we would meet this week.


Paris meeting?

CMN: Discussion of an HTML/Web apps meeting in the Spring. Possibly in Paris, in May.
... If people are likely to attend, look out for a request or survey. Be good for TF people to attend WG meetings.

JB: Understand this will be a significant meeting to shape the future of HTML and Web Applications Foundation?

PC: We'll either have decided next steps based on Santa Clara discussions, or we'll decide it at the meeting. I'm optimistic we'll decide before then, so we can do real work at the F2F.

JB: Would be good to have accessibility presence.

PC: Space shouldn't be a constraint, the proposed host is a university.
... This item is on the WG agenda.

CMN: Strongly support Paul's optimism that it'll be a technical meeting to get work done.


JB: Didn't suggest that the meeting would be process based.

SM: Did PF discuss a European F2F next year?

JS: Don't recall, although we are overdue a meeting.


<chaals> accesskey in HTML next

JF: Would like to include transcript in HTML.next discussions.

CMN: Accesskey is one thing I hope we'll look at for HTML.next. Few bugs have been listed.

<chaals> bug - accesskey should be translateable

CMN: Accesskey should be translatable.
... Don't think we need to do anything with this bug. When you translate a page you can re-create the accesskeys.
... Accesskey allows a list of characters, so you could provide values from Latin, Russian, Greek alphabets.
... Browsers should be able to change accesskeys. Authors tend to get it wrong.
... Suggest we close this as partly "not a problem" and partly won't fix.

JS: Sounds good to me.

RESOLUTION: Close bug 23284

<chaals> AcceskeyLabel can expose user information

CMN: Accesskey label can expose user information.
... The accesskey attribute and accesskeylbale DOM attribute. Can supply a list of accesskeys, browser chooses the one to use. Idea is that you could higlhight a key, provide a hint to the user.
... Problem is that it's possible to ascertain which key the user chose.
... Unconvinced that key selection is going to reveal sensitive information. Only information might be the type of keyboard someone is using.

AR: Bug mentions iframes too.
... Agree there is little that would be exposed that couldn't be found through other methods.

JF: If the fork between browser and AT were detectable, that would reveal more information. That's speculation though.

CMN: Unsure about the iframe part. We need to find out.
... With key assignment, there are many reasons why a particular key may not be available.
... Should we ask a privacy interest group about this?

AR: We're speculating. Don't think we can answer this.

JB: Could check with Wendy Seltzer?

PC: One possibility is to go to the TAG?
... Think this is an area where we should be pragmatic about getting this kind of advice.

JB: Have discussed this topic repeatedly with Wendy. From my perspective, it's worth a shot.

<JF> to clarify my concern: in the case of keyboard conflict between accesskey and Assisitive Tech, it introduces a fork (of sorts). Because of that, quessing that scripting could determine that as well, which introduces possibility of privacy/security concerns (??)

JS: IndieUI has met with the Privacy group and had a good introduction to their typical concerns.
... Think it would help to ask specific questions.
... Don't think they're well setup to provide horizontal review.

JB: Wendy is also trying to increase participation in the area.

CMN: Given timeline it's reasonable to ask for a review.

<scribe> ACTION: Chaals to ask security, privacy and TAG people to comment on bug 23614. [recorded in http://www.w3.org/2014/11/13-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-287 - Ask security, privacy and tag people to comment on bug 23614. [on Charles McCathie Nevile - due 2014-11-20].

CMN: Don't think the use case for accesskeylabel makes sense. It tells the user how to activate the thing that has the access key. That seems like the wrong approach to discovery.
... It encourages authors to do something they only do because browsers have bad implimentations.

<chaals> allow words

CMN: Request to allow words instead of characters.

<chaals> and gestures

CMN: To allow gestures instead of characters.
... Also possibility of adding accesskey with no suggested behaviour.
... No bug for the last point.

<chaals> code example for last idea: <a href="foo" accesskey>foo</a>

JF: Part of the problem is that accesskey requires a value. Trying to rework it might be a problem.
... Maybe we need to think of a new attribute - perhaps @access

CMN: We should figure out what we want to achieve. That this function needs a shortcut activation. Then ask if the accesskey attribute can be used, or do we need to throw it away.
... If the outcome is another attribute that does the same thing, that's not a good use of our time.
... We could extend accesskey to take multiple single characters separated by whitespace. We'd need to change the validator, and change the spec to allow any value because the UA will figure it out. The value of a suggestion is that only the author knows the purpose of the function.
... So the author could suggest "c" for "compose" in an email application, but the UA and/or the user might want to change that assignment.

JF: Think we should be marking elements with something. Suggest accesskey is fundamentally broken. Instead of bandaging it, we should look for a fresh start.
... New attribute with a numeric indicator as value access=1 access=2 etc. Gives us an array as a starting point for mapping.
... That would be your common denominator for all UA.

JS: Thinking we need more consideration about what this thing is there for. Early days accesskey was more in the nature of a landmark. Do we want to keep/drop that?
... If activation is the prime function, is there an IndieUI specification that could be created?

<Zakim> ShaneM, you wanted to talk about landmarks and activation

SM: John, your idea resonated with me. Agree with Janina that the original purpose of accesskey was to be a landmark.
... We addressed this in the access element. Can declare a navigation and activation function.

<ShaneM> http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/#E_access

<paulc> I have to leave to prep for the HTML WG meeting.

CMN: To speak against numbering proposal. There was confusion in the purpose of accesskey originally (activate/navigate to).
... The good thing about the access element was the ability to distinguish between navigate to and activate. Beyond that having "1" "2" etc. instead of "Compose", "Mark as spam" etc. would be a step backwards.
... Would be nothing to stop the UA actually assigning those values, perhaps in source order. Think there is value in the author having the ability to make suggestions. It's a shortcut, if you have to lookup which shortcut you need, it gets too circuitous.

JF: We haven't talked about discoverability either. That's one for next week?

CMN: Yes.

Summary of Action Items

[NEW] ACTION: Chaals to ask security, privacy and TAG people to comment on bug 23614. [recorded in http://www.w3.org/2014/11/13-html-a11y-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014-11-13 17:05:19 $

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)

Succeeded: s/Media Publishing group/Digital Publishing Group/
FAILED: s/Media Publishing/Digital Publishing/
Succeeded: s/HTML/HTML and Web Applications Foundation/
Succeeded: s/Didn't mean to suggest the entire focus of the meeting/Didn't suggest that the meeting/
Succeeded: s/the form/the fork/
No ScribeNick specified.  Guessing ScribeNick: LJWatson
Found Scribe: Léonie Watson

WARNING: No "Present: ... " found!
Possibly Present: AR Adrian_Roselli CMN IPcaller JB JF JS Joanmarie_Diggs Judy LJWatson MS MarkS Microsoft P14 PC SM ShaneM aardrian chaals inserted janina janina_ joanie paulc trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 13 Nov 2014
Guessing minutes URL: http://www.w3.org/2014/11/13-html-a11y-minutes.html
People with action items: chaals

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]