W3C

HTML Accessibility Task Force Teleconference

13 Sep 2012

See also: IRC log

Attendees

Present
David_MacDonald, Janina_Sajka, Cooper, John_Foliot, Philippe, Judy, Cynthia_Shelly, Stevef
Regrets
Laura_Carlson
Chair
Janina_Sajka
Scribe
MichaelC

Contents


<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 version 1.136 (CVS log)
$Date: 2012/09/13 16:08:47 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]