See also: IRC log
<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...
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
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
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
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
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/willfull/willful/ Succeeded: s/AAPI/accessibility API/G Succeeded: s/AT/assistive technology/G Succeeded: s/maililng/mailing/ Succeeded: s/+!/+1/ FAILED: s/keep her on plate/let her do that/ Succeeded: s/confilcts/conflicts/ Succeeded: s/removes reference to Formal Objection/removes reference to formal objection from the subhead/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** FAILED: s/keep her on plate/let her do that/ Found Scribe: MichaelC Inferring ScribeNick: MichaelC Default Present: David_MacDonald, Janina_Sajka, Cooper, John_Foliot, Philippe, Judy, Cynthia_Shelly, Stevef Present: David_MacDonald Janina_Sajka Cooper John_Foliot Philippe Judy Cynthia_Shelly Stevef Regrets: Laura_Carlson Found Date: 13 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/13-html-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]