- From: Mark Sadecki <mark@w3.org>
- Date: Thu, 17 Jul 2014 12:10:29 -0400
- To: HTML A11Y TF Public <public-html-a11y@w3.org>
Hello,
The minutes for the HTML Accessibility Task Force Teleconference 17 July 2014
are available in HTML and plain text below:
HTML:
http://www.w3.org/2014/07/17-html-a11y-minutes.html
TEXT:
[1]W3C
[1] http://www.w3.org/
HTML Accessibility Task Force Teleconference
17 Jul 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/07/17-html-a11y-irc
Attendees
Present
Mark_Sadecki, ShaneM, Adrian_Roselli, Judy,
Rich_Schwerdtfeger, Janina, Paul_Cotton, JF, Liam,
David_MacDonald
Regrets
Chair
Janina
Scribe
ShaneM, MarkS
Contents
* [3]Topics
1. [4]Identify Scribe
2. [5]Longdesc
3. [6]Media Subteam
4. [7]Useful Alt Techniques Publication
5. [8]Date-UI Overview
6. [9]HTML 5.1 Next Steps
* [10]Summary of Action Items
__________________________________________________________
<trackbot> Date: 17 July 2014
<janina__> Meeting: HTML-A11Y Task Force Teleconference
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Accessibility Task Force
Teleconference
<trackbot> Date: 17 July 2014
<scribe> ScribeNick: ShaneM
Identify Scribe
Longdesc
<paulc> Can we add an agenda item for "publish "Techniques for
providing useful text alternatives" as an WG note."?
janina__: Making progress. Hope to be done in time for the team
coordination call this afternoon.
... assuming the answers are right and meets approval we will
proceed with that.
Media Subteam
janina__: close to publishing today, but there are some items
that need to be clarified. At least one will take a little bit
of time. Publication will be pushed into next week. Hopefully
no further.
... the items to clear up are in the front and end matter.
Judy: michael confirmed that he has time to assist with getting
this out next week.
... there is a section of significant comment pending (from the
education outreach working group). Typically there would be an
editorial note in the document so that readers know there is
additional content coming.
janina__: this is in the very first section - explanation of
how various disabilities effect a users ability to access the
internet.
Judy: we are not going to make the updates right now - just let
readers know it is coming.
MarkS: actually the editorial note is already there.
Useful Alt Techniques Publication
janina__: everything is approved. is there a way to get the
final draft with Sotd circulated?
... for example the document we reviewed still says "Draft".
paulc: the status section is probably inappropriate for a
working group note. surprised I didn't catch that.
<paulc>
[11]http://lists.w3.org/Archives/Public/public-html-admin/2014J
un/0055.html
[11] http://lists.w3.org/Archives/Public/public-html-admin/2014Jun/0055.html
paulc: the working group decision was made on 20 June. Who is
on point? Why has this not yet been published?
... at what level of decision making do you want approval of
the Sotd?
janina__: Just chair level would be fine.
Judy: Or not even that.
paulc: the body of the document has not changed since the CfC -
is that correct?
janina__: I haven't seen the final so I don't know. I would
hope not.
Judy: It is a fine question though. Seems like something we
should check.
paulc: Delegating to the task force coordinators and the
editors to clean up the Sotd etc. is a fine approach.
Judy: We would want to coordinate anyway so we can make an
announcement.
... publication date needs to get looped through too
paulc: there are two formal objections on this document. the
objections are about it being on rec track.
... so I have an action to go back to them once it is a note to
ask them to remove their formal objection.
<paulc>
[12]http://rawgit.com/w3c/alt-techniques/master/index.html
[12] http://rawgit.com/w3c/alt-techniques/master/index.html
<paulc>
[13]http://rawgit.com/w3c/alt-techniques/master/index.html#refe
rences
[13] http://rawgit.com/w3c/alt-techniques/master/index.html#references
paulc: I just scanned through the document and there is a
broken reference.
Date-UI Overview
<paulc> Robin Berjon; et al. HTML 5.1 11 December 2008. W3C
Recommendation. needs to fixed
janina__: Prepared with a report.
calendaring / date picking are frequently an a11y nightmare
looking at the chain... all that gets to the communicated back
to the server is a simple string that identifies the date.
scribe: sometimes there is additional logic that customizes the
calendar.
... most user agents have accessible built in date pickers
... customization / business logic is required to, for example,
allow limiting of the range of selectable dates.
... calendar representations are something that vary via
locale.
... what's the first day of the week? non-gregorian calendars
I don't have a full proposal. But I wonder if there is a way to
get the user agent implementors to offer a choice of which
widget should be presented when a date input is requested?
scribe: this is sort of a classic approach to A11Y
JF: This is a user agent problem. A browser plugin? Might be a
solution, but it is really just another "roll your own"
... abstracting it down might reduce the number, but the plugin
will still not be a strong solution.
... Boils down to authoring guidance. It would be nice if the
widgets in the browsers had more hooks for styling and control.
... user agent problem.
Judy: Seems like an interesting issue, but more in agreement
with John.
... back in the gallery of accessible components work there was
thinking about this.
... not catching the HTML5 connection at this point.
janina__: I don't see a connection with the spec yet. But there
is clearly a problem in this space.
Judy: Maybe we should hand this off to WAI coordination then.
<Zakim> MarkS, you wanted to agree with JF and point out that
there may be progress on this
MarkS: Agree with John. Encourage authors to use standard
widgets. The complaint I hear most is that they cannot style
them.
... I hear now that there is an option in Chrome to style
elements in the shadow dom. If that becomes standard and works
across browsers, authors may be encouraged to use native
controls/widgets more.
janina__: let's not forget about the business logic. The reason
people do their own is to restrict date ranges.
... one good available option that would help would be a right
click option to just type in a date. If you are comfortable
with that interface, it is a very a11y way to do it.
Judy: what about mobile - would it work there?
MarkS: What about encouraging html5 to add support for
something like the patterns attribute to restrict date input
values.
JF: What about using CSS to restrict input values on date-time
widgets?
ShaneM: I kind of like Mark's suggestion - is there a way to do
it?
HTML 5.1 Next Steps
JF: We were supposed to talk about access keys today. We are
not prepared.
no obvious benefits to accesskey right now. any new
requirements would be on the browser, not on HTML itself.
[14]http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/
[14] http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/
<richardschwerdtfeger> [15]http://www.w3.org/TR/xhtml-access/
[15] http://www.w3.org/TR/xhtml-access/
scribe: there was work on this.
... but access + key = accesskey. unless the user can override
the keybinding it doesn't solve the problem.
... opera had a nice way to deal with it back in the day.
richardschwerdtfeger: Why not allow the user agent to do it in
a device independent way?
... look at the access module. Think about it as if you were
going to make it device independent. Could it define actions
that indicate intent?
JF: discoverability remains a problem. People need to be able
to learn what key bindings / actions are avialable and what
they do
richardschwerdtfeger: what you do is register them and allow
the user to pull up list
JF: and those are user agent functions. not code functions.
There could be some metadata that advises the user agent.
richardschwerdtfeger: how does the author specify a mnemonic
and a mapping?
JF: I have always said there is a need for this. But that the
implementations are bad. And there are issues with
internationalization issues too.
richardschwerdtfeger: the browser knows what the language of
the user is. It could do the transformation to different
mappings.
... we do this for forms now.
janina__: Let's not forget that this would be useful in SVG.
Would an extension spec be useful?
<MarkS> +1 to extension spec
richardschwerdtfeger: it could be an extension spec.
<MarkS> scribe: MarkS
SM: I appreciate the concern. The spec I linked to was never
finished, but the idea was that it was possible, as an author
to provide the mapping, an that users can override that.
... device independence adds additional complexities...
JS: perhaps this is an IndieUI thing
SM: these are all discussions that can be had developing an
extension spec
JF: we need to get browser vendors on board.
... had this available for a really long time, but poorly
implemented to date.
RS: and poorly designed
JB: is this an extension spec or an HTML5.1 feature
<JF> JF notes taht accesskey is already part of HTML5:
[16]http://www.w3.org/TR/2011/WD-html5-20110525/editing.html#th
e-accesskey-attribute
[16]
http://www.w3.org/TR/2011/WD-html5-20110525/editing.html#the-accesskey-attribute
DM: does anyone recognize extension specs?
JB: they are equal citizens in the open web platform
JS: important for us to look at extension specs from other
groups as well.
<paulc> Examples of extensions specs: EME, MSE, longdesc,
<picture> (now folded in), srcset (now folded in), Ruby (now
folded in), etc.
<Zakim> ShaneM, you wanted to talk about the access module
<paulc> Lots of other examples
PC: several extension specs have been folded in too. There are
a lot of other WGs that are doing them as well.
... web performance for instance, are doing lots of extension
specs
... there is no difference in full spec or extension spec for
getting browsers to implement
<JF> <input type=submit accesskey="N @ 1" value="Compose">
JF: accesskey is already in HTML5. one of the proposed way of
doing keybinding is a space separated list of values
... as an attempt to avoid conflicts.
... an extension spec will either build on this or be in
conflict with this
JS: or to replace as well
... sounds like there is interest in this.
<ShaneM> I will champion this extension if there is interest.
JS: we are currently going through a list of topics to decide
what we want to focus our future work on
<JF> I am happy to be involved in a sub-team on this topic
JF: because its an existing attribute, it might lend weight to
prioritization.
MS: glad to see this prioritization process is working.
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version
1.138 ([18]CVS log)
$Date: 2014-07-17 16:09:05 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 17 July 2014 16:10:30 UTC