W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

30 Aug 2012

Agenda

See also: IRC log

Attendees

Present
John_Foliot, Mike, Janina, hober, Plh, Judy, Cooper, paulc, James_Craig, Rich
Regrets
steve
Chair
SV_MEETING_CHAIR
Scribe
janina

Contents


<trackbot> Date: 30 August 2012

<scribe> scribe: janina

<Judy> redialing

<paulc> Staying on mute.

jb: Text met Tuesday as usual, used time as a work session on I-30 primarily
... Primary focus is to update the presentation of the extensive evidence in InstateLongdesc
... To provide a clear summary, top level read, for which the various links then provide detail
... Also the concern that the I-204 objection is clouding clear consideration of I-30
... One piece still missing is some kind of statement clarifying current disupte on 204, or what the resolution is

<Judy> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

<Judy> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc

jb: Just heard fromLaura who wants to know there's TF approval before she moves the staged presentation to the CP
... The cloud relates to the discussion of the last year that suggests ARIA-DescribedBy might be an appropriate mechanism for long textual description, meanwhile the I-204 status, and the language of Sec. 7.1 is still in doubt fecause of the formal objection

rich: Asking what it is that's missing about DescribedBy

jb: A statement of the resolution of the I204 dispute and the impact for whether how that relates to the I30 reconsideration

james: I was away last week, but have tried to get to the bottom of the FO since returning. I see two issues: 1) jurisdiction of HTML vs PF WG wrt to speccing ARIA implementation, and 2) wording that implies exposing description at all times (fixing this may be an editorial change)

<hober> I've captured these two issues in HTML5 spec bugs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744 (update the wording to not be specific to wai-aria) and https://www.w3.org/Bugs/Public/show_bug.cgi?id=18745 (update the wording to not imply that hidden="" elements would show up in the ax tree)

jb: Responding procedurally ...
... Understand you were away
... Request that we keep to agenda order to be efficient on this call.

james: Has asked whether issue of FO was about making hidden content visible via AT

jf: In fact, yes, but not the only question

rich: q+
... I'm concerned that existing 7.1 text selectively displays content author had specified to be hidden
... It would significantly break the UI appearance of IBM's existing products

<JF> +1 to adopting revised text

jb: Asking for any comments to the new InstateLongdesc wrapper text, or any objections to it?

<jcraig> rich, there are ways to "display" things without breaking the main UI, but I will wait to respond tip we get to that topic

jb: Want to note again the intent to add just a bit more relating to I204 status and implication

<Judy> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

<Judy> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc

mike: uncertain whether we have qurom for a resolution?

jb: Also sensitive time issues here with the HTML Chairs requesting stableCP text by today
... Are there objections to adding the summary wrapper text to InstateLongdesc?

Mike: There seem to be no objections

Issue-30 Reconsideration: Going Forward

Issue 204 PFWG's Formal Objection: Status and Updates http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0256.html

js: Will note that PF was not at full force last week, however there was significant PF participation in the FO and it was unanimous among those present, so consensus is a reasonable understanding

<MikeSmith> Reword text adopted by ISSUE-204 to avoid certain implications

js: In addition, we should note two terms of great problem in the adopted language, "encourage" and "such as"
... This is not established technology, but experimental

james: Want to acknowledge agreement that the particular wording adopted could potentially break current implementations

<MikeSmith> drop WAI-ARIA scope restriction in the text adopted in ISSUE-204

james: Have been discussing potential wording changes with Ted, whose proposal this is
... Some APIs allow semantics marked hidden, but not all
... Despite the wording there ws never intention to throw this into DOM

<jcraig> Where accessibility APIs allow nodes to be marked as hidden, User Agents are encouraged to expose the full semantics of hidden="" elements when they are referenced via relationship attributes (such as aria-describedby in WAI-ARIA). This allows Assistive Technologies to access the content structure upon user request, while keeping the content hidden in all presentations of the normal document flow.

jf: Seems to access this additional info reques user has AT.
... Much HTML-WG discussion exposed a long text description requirement for users without AT

james: You are correct that it relies on AT as written, we could change that

jf: This seems half-baked to me. We have no knowledge of this manifests, yet it's in the spec as what we will do
... Just to clarify, we're talking about the hidden attrib, a boolean attrib
... That means a switch option somewhere

<paulc> rssagent, generate minutes

<MikeSmith> ask hober

js: This redraft, plus the discussion that followed in this meeting to change even more of the language offered above, makesPF's case that this proposal is inappropriate for a cross platform standard

ted: Intent was not to insert formally hidden text into a visible DOM, we need to fix that
... Intent not to say antyhing specific of ARIA

<hober> <label for>, <td headers>

ted: header attrib on table, for on label, examples of ...
... Would be unusual not sure we want expansive language
... So by process of elimination, I think only DescribedBy and LabeledBy

rich: One design pattern requres tab reference aria-controls, if hidden, this encourages visible
... All browsers today, hidden descripts are not mapped to AAPIs, because author wants them hidden
... All AAPIs map hidden descript to strng

Ted: Exposing the full semantics was not intended to mean exposing to the browser
... We don't want to constrain AAPIx from improving in the future

Rich: If you want a function like this, define a different attribute that does what you want, but don't redefine an existing attribute that's used today differently
... If you want a function like this, let's create one in ARIA 1.1 and lets define it appropriately

jb: Want to summarize that there has been agreement here that language as was approved is not right, and there will be follow up discussion

ted: Trying to improve the wording that was there

jb: And hearing more discussion on how new wording would be a problem, so discussion needs to continue
... ARIA TF is the appropriate place for that

<paulc> There is a queue.

<Zakim> jcraig, you wanted to say, this is how Mozilla exposes describedby today

<paulc> The locations for joint PF and HTML WG discussion is THIS TF not PF.

james: Want to point out that this is how Mozilla exposes content this way today
... The point is to expose semantics when available and appropriate--not to limit future implementations
... won't work off the bat today
... is possible in some today

paul: Wants to point out that correct place to discuss HTML bugs with a11y is this TF, not ARIA

jb: ARIA design is in the scope of PF

<jcraig> this is an HTML decision about HTML attributes

<jcraig> that includes aria attributes

<JF> Janina: wondering where the fire is here? Why do we need to rush forward on this?

janina: Suggest it's inaccurate to suggest this needs resolution now in HTML 5 but at the same time say it's not about longdesc

mike: Seems more discussion is needed

jb: But a decision has been made and objected to,

mike: We can try to see if we can get agreement to see if the spec can continue without objection on this
... Text on the table for refining the language seems what we can discuss

rich: If it means this discussion redefines ARIA spec, I oppose it
... If it's something new, then it needs to be don in 1.1

mike: Anything else urgent for today?
... Janina will chair next week?

janina: yes

mike: scribe for next week?

[silence]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/08/30 16:11:38 $

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/FO since returning/FO since returning. I see two issues: 1) jurisdiction of HTML vs PF WG wrt to speccing ARIA implementation, and 2) wording that implies exposing description at all times (fixing this may be an editorial change)/
Succeeded: s/boulian/boolean/
Succeeded: s/redratf/redraft/
Found Scribe: janina
Inferring ScribeNick: janina
Default Present: John_Foliot, Mike, Janina, hober, Plh, Judy, Cooper, paulc, James_Craig, Rich
Present: John_Foliot Mike Janina hober Plh Judy Cooper paulc James_Craig Rich

WARNING: Replacing previous Regrets list. (Old list: rich, leonie, laura)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ steve

Regrets: steve
Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0273.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 30 Aug 2012
Guessing minutes URL: http://www.w3.org/2012/08/30-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]