[1]W3C
[1] http://www.w3.org/
- DRAFT -
SV_MEETING_TITLE
13 Nov 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/11/13-html-a11y-irc
Attendees
Present
Regrets
Chair
Chaals McCathie Nevile
Scribe
Léonie Watson
Contents
* [3]Topics
1. [4]longdesc
2. [5]canvas
3. [6]HTML.next
4. [7]Paris meeting?
5. [8]HTML.next
* [9]Summary of Action Items
__________________________________________________________
<janina> akim, ??P14 is me
<scribe> scribe: Léonie Watson
longdesc
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.
canvas
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 ->
[10]https://www.w3.org/Bugs/Public/show_bug.cgi?id=27263
[10] 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. ->
[11]https://www.w3.org/Bugs/Public/show_bug.cgi?id=27264
[11] 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.
HTML.next
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.
+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.
HTML.next
<chaals> [12]accesskey in HTML next
[12] https://www.w3.org/WAI/PF/HTML/wiki/Wishlist_for_HTML5.1#Accesskey
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> [13]bug - accesskey should be translateable
[13] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23284
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> [14]AcceskeyLabel can expose user information
[14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23614
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
[15]http://www.w3.org/2014/11/13-html-a11y-minutes.html#action0
1]
[15] 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> [16]allow words
[16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=13576
CMN: Request to allow words instead of characters.
<chaals> [17]and gestures
[17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23615
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>
[18]http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/#E_a
ccess
[18] 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
[19]http://www.w3.org/2014/11/13-html-a11y-minutes.html#action0
1]
[19] http://www.w3.org/2014/11/13-html-a11y-minutes.html#action01
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [20]scribe.perl version
1.140 ([21]CVS log)
$Date: 2014-11-13 17:05:19 $
__________________________________________________________
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[21] http://dev.w3.org/cvsweb/2002/scribe/
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 [22]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[22] 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_Digg
s Judy LJWatson MS MarkS Microsoft P14 PC SM ShaneM aardrian chaals inse
rted 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: [23]http://www.w3.org/2014/11/13-html-a11y-minutes
.html
People with action items: chaals
[23] http://www.w3.org/2014/11/13-html-a11y-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of [24]scribe.perl diagnostic output]
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm