See also: IRC log
<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
<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.
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.
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> 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> http://rawgit.com/w3c/alt-techniques/master/index.html
<paulc> http://rawgit.com/w3c/alt-techniques/master/index.html#references
paulc: I just scanned through the document and there is a broken reference.
<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?
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.
http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/
<richardschwerdtfeger> 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: 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.