- From: Michael Cooper <cooper@w3.org>
- Date: Thu, 13 Sep 2012 12:08:50 -0400
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
- Message-ID: <50520512.9050103@w3.org>
Minutes of the 13 September 2012 HTML Accessibility Task Force meeting
are posted to http://www.w3.org/2012/09/13-html-a11y-minutes.html and
copied below.
HTML Accessibility Task Force Teleconference
13 Sep 2012
See also: IRC log <http://www.w3.org/2012/09/13-html-a11y-irc>
Attendees
Present
David_MacDonald, Janina_Sajka, Cooper, John_Foliot, Philippe, Judy,
Cynthia_Shelly, Stevef
Regrets
Laura_Carlson
Chair
Janina_Sajka
Scribe
MichaelC
Contents
* Topics <http://www.w3.org/2012/09/13-html-a11y-minutes.html#agenda>
1. Issue-204 Status and Concerns Discussion
<http://www.w3.org/2012/09/13-html-a11y-minutes.html#item01>
2. Issue-30 Status & Next Steps
<http://www.w3.org/2012/09/13-html-a11y-minutes.html#item02>
3. Issue-31B (Sec. 4.8)
<http://www.w3.org/2012/09/13-html-a11y-minutes.html#item03>
4. Issue-206 Open Discussion
<http://www.w3.org/2012/09/13-html-a11y-minutes.html#item04>
5. The Task Force at the TPAC
<http://www.w3.org/2012/09/13-html-a11y-minutes.html#item05>
* Summary of Action Items
<http://www.w3.org/2012/09/13-html-a11y-minutes.html#ActionSummary>
------------------------------------------------------------------------
<trackbot> Date: 13 September 2012
<janina> trackbot, start meeting
<trackbot> Meeting: HTML Accessibility Task Force Teleconference
<trackbot> Date: 13 September 2012
<janina> ce Teleconference
<scribe> scribe: MichaelC
<Stevef> janina: yes will be there soon
<Stevef> client work...
Issue-204 Status and Concerns Discussion
js: to recap, there was a Formal Objection
followed by some alternate proposals
chairs have agreed to incorporate one of those
which is in the draft now
will continue to refine that as needed
that version does not contain the substance on which PFWG objected
Tim has sent a note of encouragement
possibly in lieu of any further formal response to the objection
http://www.w3.org/mid/843B736C-BD48-425C-99CD-795FA08BA82C@w3.org
plh: this has been incorporated by editor
jb: yes, though has taken further suggestions that had not been vetted
by the groups
<plh> http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute
<Judy> jb: we will be reviewing the additional changes
js: any issues to explore based on the new language?
jf: consider a hyperlink in a table header that is hidden with @hidden
which is a real world design pattern
this could lead to tab-focusable element that is not visible
one way to address would be to declare that non-conforming and raise a
validation error
another would be to specify that hidden content that is referenced
should be exposed to user
perhaps like show / hide navigation tools are done or something
js: language encourages accessibility APIs to add support for exposing
semantic richness to assistive technologies
is there any limit to the kinds of semantics this would encompass?
i.e., would it be possible to deal with hyperlinks across full range of
assistive technology?
cs: hyperlinks would get flattened because of display:none
authors should not reference hidden content that contains structure or
active elements
jf: but if we expose full semantics, isn't a link part of that?
cs: if accessibility APIs support rich semantics and interactive elements
then it would be possible to show content and navigate hyperlinks
UI might be like summary/details (just a suggestion)
a lot of work needed to make this happen
js: so the object assistive technology knows about is provided by the
user agent
cs: if I were designing, would put the rich content in the DOM and the
accessibility API
could just put in the accessibility API, but wouldn't be
visible/navigable by mainstream users
jf: consider a screen reader that is also a screen magnifier
should work for this
cs: I would access accessibility API, open a window, instantiate a
browser instance, build a DOM, and render it
either the assistive technology or the browser could build the UI
jf: concerned that if this remains underspecified we'll have pain
I used to argue against @accesskey because of lack of discoverability
that same argument has been applied to @longdesc more recently
so really concerned about suggesting a technique that doesn't specify
discoverability
js: discoverability is a new aspect of this we need to address
but meanwhile on the hyperlink question
jf: WCAG 2 requires hyperlinks have visible focus
js: CS has given a path to that
cs: there is a lot of work to be done
since it's not done, it's vague in the spec right now
but if you or someone proposes a UI, that would be a helpful contribution
js: so what is exposed to the accessibility API has a full set of DOM
features?
cs: yes, it's just a subtree
js: to test limits
would canvas, video work?
cs: no technical reason it can't work
may not be good idea in practice
but that's a design pattern issue
jf: I'm just worried that this is so under-specified
worried this could be a technique that allows willful violation of WCAG
js: first step is somethign that works, whether it's a good idea is separate
sf: hearing that assistive technology could just build an alternate UI
some assistive technology have a range of alternate views
right now it's vague
don't see this aspect being dealt with in short term
there are so many other features to implement
so shouldn't get stuck on this feature right now
js: moving on to discoverability issue
one use case covered a lot by Rich, where intent of hidden content is to
stay hidden to all users for some specific reason
so author is controlling, and wants control over, when it's exposed
while we want programmatic discoverability so assistive technology can
tell user "there's something hidden there"
which is a clash
shouldn't leave this to UI implementation
need a flag that addresses both use case
cs: hidden content not referenced by an IDREF should be just hidden
hidden content referenced by an IDREF is associated with the referring
element
is a property of that element, as it were
so should be exposed in that circumstance
browser can tell which of those situations you're in
jf: sounds like presence of an IDREF switches the value of the @hidden
attribute
cs: sort of
like display:none where in certain circumstances the accessibility API
is populated
if author didn't want that, they wouldn't reference the object
<scribe might have missed some details here>
author could choose to only set e.g., @aria-describedby when they want
the association to be made, so it's fully hidden until the IDREF exists
jf: I guess sort of works
cs: addresses showing content when author not expecting
would like to see some code samples exploring these use cases
js: Steve, thoughts?
sf: +1 to CS
note that assistive technology do what they want anyways
defining doesn't mean they'll follow
js: so propose we should put something about this into the section
since it addresses use cases and defines how software can tell which use
case applies
cs: author turns on ability for user to access hidden content by adding
IDREF
js: please make proposal around this
cs: will do
dmd: +1 to CS
Issue-30 Status & Next Steps
jb: back on 204, note Sam clarified on list that potential removal of
ARIA from HTML spec no longer under consideration
... on HTML-ISSUE-30
note HTML-ISSUE-204 was part of a dependency chain leading back to this
this TF has twice confirmed support for a change proposal worked up by
Laura Carlson
<Judy> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
neither the position nor details have changed
but did review some updated text from the text sub-team
to better explain the supporting evidence
and pulled in information from the requirements page
needed to add a statement about dependency chain
now HTML-ISSUE-204 progressing, we have something we can say
<Judy> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc
little more cleanup to do on the change proposal
<Judy> the subhead should now read: Relation to Issue 204 and ARIA
describedby
expect that to be in soon
removes reference to formal objection from the subhead
comments?
would like to get review and ready for HTML WG survey within a few
business days
intent was to be matter-of-fact and orient better
to the evidence etc.
would like this language in place by early-to-mid next week
expect call for updated consensus of TF mailing list today
at next text sub-team meeting, would review comments
invite TF members to join the call (Tuesday 18 Sep 2012 17:00 UTC)
objection to this process?
<Stevef> no objection
<JF> +1 to Judy's proposal
so plan to confirm updated consensus at that meeting, not wait for
following TF meeting
<Judy> this would specifically be with the changed subhead as well.
mc: any TF member can make the edit
jb: Laura has been making changes, prefer to keep on her plate
<Judy> s/keep her on plate/let her do that/
js: input?
trying to make a helpful change, time-sensitive
<Judy> jb: survey will go out before 1pm, we'll need to change it in the
wiki before then
Issue-31B (Sec. 4.8)
js: now other issues clearing out of the way, we can look at this more
need to bring HTML chairs / WG up to speed with the advice that
conflicts with WCAG and the alternate version Steve prepared
want to leave that with just lexical definition of @alt, let the other
resources talk about usage
also there are examples that don't use alt text well
want to provide suggestions for improving it
need some people to help with that, shouldn't be too hard
jb: the priority is the first part of this, related to guidance
dmd: expect to discuss details with you soon
js: DMD is lead author in highlighting where the advice conflicts
Issue-206 Open Discussion
js: not sure if this is in active debate
the meta generator language has been approved to be removed (not sure if
that edit is made yet)
<Stevef> issue 206 is quiet at the moment
should explore whether substitute language should go in
any active discussion?
jf: haven't seen activity on list
js: there have been circumstances in which a validator shouldn't
penalize missing alt when the authoring tool couldn't do anything about it
has a case been made to talk about this in the document?
could mean the conditions for validation change
meaning a static element in the document might not be up to date
sf: no discussion of that
js: will bring that proposal up
note there's exploration of taking this to HTML.next
The Task Force at the TPAC
js: TF has no separate time at the Technical Plenary, but typically
meets as part of the HTML WG meeting on Thur / Fri that week
will ask more and more about agenda for that
trackbot, end meeting
Summary of Action Items
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.136 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2012/09/13 16:08:47 $
--
Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>
Received on Thursday, 13 September 2012 16:09:45 UTC