HTML Accessibility Task Force Teleconference

25 Aug 2011


See also: IRC log


Janina, Mike, John_Foliot, Judy, Michael_Cooper, Léonie_Watson, Rich


<trackbot> Date: 25 August 2011

<scribe> scribe: JF

MC: summary of the work of bug-triage team

members of team include Leonie, M. Cooper, Marco Ranon, Hans Hillen, Everett Zuefeltt

have a working plan for the next few weeks

<MichaelC> Bug triage minutes 23 August 2011

<MichaelC> bug triage sub-team looking at a11y bugs since LC that aren't yet a11ytf

<MichaelC> to decide if they need to be TF priorities

JS: looking at the consensus policy, and see if we can tweak it to better reflect how we are working today

<MichaelC> towards a next step which is pushing back on priority assignments made by chairs

<MichaelC> if needed

<MichaelC> a window for that in early september

JS: it appears for example that much of the work has been emerging from the sub-teams

<MichaelC> next sub-team will look at all bugs since LC and determine if they have a11y relationship

<MichaelC> then proceed with triaging those over the upcoming quarter

it seems however that we are voting 3 times on the same issue

which leads to some confusion

JS: if we can reduce the amount of voting, even down to 2, then that is a win

would like to see us acknowledge that much of the heavy lifting is being done at the sub-team level

and if we assign work-effort to a sub-team, that this TF then support the expertw charged with that work

so perhaps allow the sub-teams to work a little more informally

JS: looking at both media and canvas, this larger TF normally accepted the recommendations of the sub-team without question

JB: have started to brains-storm, but we need to be very clear on what problem(s) we aqre trying to solve

it seems that perhaps the process is overly complex

JB: the multi step nature means that it can cause some delay

perhaps associated to the WBS survey mechanism

JB: so, envisioning different scenarios, are the ways we can avoid being delayed. Perhaps 2 levels of formality/process

so for example bug filing and issue of re-open requests and what-not

Perhaps those could be assigned to the sub-groups. But there may also be other things that would be better handled with a more formal process

so it would be useful to enumerate issues and scenarios where the process is stalling work, and then look to see if we can revisit the process there

JS: one thing specifically missing is because we do not say anything about the sub-teams in the consensus policy process

so we cannot point to the fact that the sub-teams are working on a particular issue/point

JB: not sure however if that addresses the requirement for different work-flow

JS: where to kick into a more formal process is worth investigating
... Looking at issues within the media sub-team, that group discussed and reach agreement, and then it was pushed through often directly to the larger

WG without it going through this Thursday meeting

(it skiped right overthis group), and it was non-controversial

JB: are you then proposing to draft something different for others to review?

JS: yes, exactly. just seeking feedback
... likes that the facilitators can guide discussion and move things forward

agree that there are other issues that might be more sensitive, and so sensitive things are likely to end up in surveys

media, canvas, aria-mappings were less controversial

LW: agree in principle with what Janina is proposing

JS: wonders if Mike TM has any feedback about this line of process discussion

MS: the way the HTML5 process has evolved is that it was originally written by maciej, and then has been fine-tuned over the longer haul
... but it all starts with somebody initially writing up something, and then seeking wider feedback
... so that would need to happen. but having a streamlined process is overall a good thing

JS: seems I am volunteering to write a new draft - hopefully I can have that in early September
... ASking Rich for feedback on Canvas

RS: waiting for Ian to respond to Charles Pritchard re: changes to focus management
... there was something for scroll-into-view

talked with Jonas, and if wee can put the paths in, then we can use a CSS property that is already in the layout engine

just need to ensue that the CP for that, that anything having to do with CSS functions would also be applicable there

so agreed that it could be closed

RS: another defect is on content-editable and designmode

Ayreh agreed that this needed to be re-written, and that is moving forward

JS: this will be re-integrated into the HTML5 spec

RS: the other issue is around the standardized keyboard input

instead of putting those features into that part of the document, they wanted to put it into a seperate authoring spec

RS: Ayreh has created a seperate document - issue is that it is a document outside of W3C, even though it is actually a good idea

there is some discussion about how to bring that into the W3C. Ayreh not keen on following the W3C process

RS: reading the note from Ayreh about W3C Community Groups

so this looks like Ayreh will look to use this forum to bring it back into W3C

RS: I think this is a good thing that the W3C is making things more open and nimble then it's a good thing

and this editing spec likely moving into W3C space is an example of why

<richardschwerdtfe> https://plus.google.com/stream/circles/p2c387a7408241602

RS: not sure if everyone can read that, but this is/was Ayreh's posting

<richardschwerdtfe> http://www.w3.org/community/editing/

RS: Have heard a bit about Community Groups, but curious how that process and not being on Rec Track works

JB: I am also investigating this at this time, but not ready to answer at this time
... text sub-team update

have been looking at the table summary issue, the meta generator issue, and the response to Jonas' longdesc CP

with meta-name and summary we are still looking for more feedback

John's draft response to Jonas - he's looking for more editorial feedback

JB; we have also noted that the next 2 Mondays present schedule conflicts

so we are looking at a possible day-shift as a one-off

(wonders if aiming for a Tuesday 4:00 PM Boston time would work - wondering on impact for European attendees)

JB: but looking to move it to a more regular time slot that is not Monday
... will try some alternative dates and times on the list

LW: the ideal time for me would be Tuesday before or after the bug-triage call (seems like tht is 11:00 PM Bos)

JS: concerned about making a permanent move as that might impact on European participation

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/08/25 16:04:13 $

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/inofrmally/informally/
Succeeded: s/oinofrmally /over/
Succeeded: s/Chalrs/Charles/
Succeeded: s/ide/idea/
Succeeded: s/udate/update/
Found Scribe: JF
Inferring ScribeNick: JF

WARNING: No "Topic:" lines found.

Default Present: Janina, Mike, John_Foliot, Judy, Michael_Cooper, Léonie_Watson, Rich
Present: Janina Mike John_Foliot Judy Michael_Cooper Léonie_Watson Rich
Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2011Aug/0567.html
Found Date: 25 Aug 2011
Guessing minutes URL: http://www.w3.org/2011/08/25-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

[End of scribe.perl diagnostic output]