See also: IRC log
<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.
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.
+1
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.
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]