HTML Accessibility Task Force Teleconference -- 31 Mar 2011

<trackbot> Date: 31 March 2011

<janina> Meeting: HTML-A11Y telecon

<janina> Chair: Janina_Sajka

<janina> agenda: this

Canvas subteam update

<oedipus> RichS' update on Canvas Subgroup (2011-03-30) http://lists.w3.org/Archives/Public/public-html-a11y/2011Mar/0225.html

<oedipus> HTML WG Issue-131 (caret for canvas) CP objection poll http://www.w3.org/2002/09/wbs/40318/issue-131-objection-poll

<oedipus> HTML WG Issue-131 (caret for canvas) CP objection poll results http://www.w3.org/2002/09/wbs/40318/issue-131-objection-poll/results

<oedipus> HTML A11y TF Canvas Subgroup CP being polled for HTML WG Issue-131 http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection

<oedipus> ian hickson counter proposal http://lists.w3.org/Archives/Public/public-html/2011Mar/0521.html - as RichS' comments point out, hixie's counter proposal has several technical flaws and does not address magnification needs sufficiently

<MichaelC> scribe: Leonie_Watson

<MichaelC> Topic Sub group updates: Canvas

<MichaelC> GJR: RS has created a change proposal for issue 131, but IH believes it to be unsound.

<MichaelC> GJR: When the TF completes something that is seen as a deliverable, what do we have to do to get that accepted?

<oedipus> poll closes today 2011-03-31

JB: At a minimum you would want to provide that clear statement of the survey.
... To acknowledge that the consensus came from a wider range of sources.
... Restating the facts and restating the concerns would be helpful in getting those things on the record again.

JS: Can I remind everyone that the chairs have asked people not to +1 or repeat information.

<paulc> Please note that all surveys say: "Comments that are NOT actual technical objections to material in the change proposal ARE NOT ACCEPTABLE and WILL BE IGNORED. "

EC: I think it's reasonable and healthy for people to have other proposals. They'll be evaluated on their merits.

JB: I don't disagree with that at all.

<oedipus> 1. the "alternate" proposal is the canvas spec text iitself; 2. canvas subgroup tasked to provide spec ready solutions

GJR: The alternate proposal is the canvas spec text itself, and that has grown and changed over time. The sub group was tasked with taking that text and looking at there the holes might be.

<paulc> http://www.w3.org/2002/09/wbs/40318/issue-131-objection-poll/

PC: You guys need to read the poll...

<paulc> "Comments that are NOT actual technical objections to material in the change proposal ARE NOT ACCEPTABLE and WILL BE IGNORED. "

<oedipus> paulc, how, then, do we make issues such as the one under discussion to the chairs and WG?

PC: The text says comments that are not technical objectsions are not acceptable and will be ignored. I want to warn you that from what I can tell, these kinds of comments about the validity/strength of where a proposal comes from will be dismissed.

CS: Does it comes down to the fact that oen proposal was vetted by vendors and the others was not make the difference?

<JF> +q

<oedipus> what is the use of the poll if feedback is so limiited?

CS: Is consultation with a wider array of vendors significant?

PC: Yes, providing it's demonstratd through technical comments within the change proposal.
... Just saying you talked to your mother about your change proposal isn't germaine.

<oedipus> B.S

JB: The potentially narrow wording of some of the questions within the survey has fuelled some f the difficulty.

<JF> Note: the chairs are hesitant to reorganize the poll questions completely, unless there are WG members who truly feel they cannot sensibly respond to the current poll. - http://lists.w3.org/Archives/Public/public-html/2011Mar/0742.html

JB: I hope you do look at the evidence of where something was vetted.

GJR: I don't think you heard what I said in reply to Eric. This isn't being pulled out of our sleeves, it's a dedicated effort by the TF to come up with identification of where the holes are, how they can be plugged and the relevant changes to the spec.
... We've had this discussion many times before, the way the survey questions are phrased/posed, makes us question how we're supposed to approach thes things?

<oedipus> RichS is a C T O at IBM not someone's mother-in-law

JF: It's hard to find examples when we're talking about future implementations. We're also supposed to be building consensus, but when you have two opposing perspectives it isn't clear how we resolve that.

<paulc> From the survey lead in text: We will not do any numerical counting all the votes. All we will look at is the objections and rationale presented.

<JF> CAn the chairs define what they consider "consensus>?

PC: What I'mn hearing is a more general distain for the survey process. I'd suggest you all have more valuable work to do than discuss this process. I suggest you describe your concerns and JS and JB can take them to the chairs.

<oedipus> paulc, doesn't the small number of comments that are actually dealt with in these surveys ring a warning bell to the co-chairs

PC: I hear your pain, but this is the process the chairs have put in place. We did a call for consensus, which was approved by the WG.

<paulc> One other comment:

<paulc> I anyone has trouble understanding a survey they should respond to the Straw Poll email asking for a clarifiacation.

<oedipus> this isn't the first time that the survey format has been questioned, at least in this TF, for quite some time

<paulc> They chairs are very open to explaing or even adjusting the survey(s) so they are clearer.

<paulc> it only makes our evaluation easier.

<JF> +q

<oedipus> 3 responders to poll on HTML WG Issue-131 are: hixie, RichS and SteveF

<oedipus> rich does a very good job of explaining why the canvas subgroup's CP should be considered and the problems with hixie's counterpropsal

JF: How are the chairs assessing consensus here? It seems that some issues are stepping into the realm of philosophy, it's not even a question about the text itself, but where the text should be. But you're not asking for philosophy, you're asking for technicalities.

PC: We measure consensus by trying to find the change proposal that generates the least objection.

EC: What I hear is a number of people saying the chairs should recognise authority, and that people are making appeals to authority, and I don't believe that's what this group actually wants.
... Whilst this group has a great deal of accessibility expertise, there are probably a lot of people outside of this group that have expertise in other areas of the web, and we don't want the opinions of people here shut out because they're not recognised as experts in other areas.

<paulc> Again from the survey lead in text: This is not a popularity contest. The Working Group Decision will be based on the strength of objections, not the number of people expressing them.

<oedipus> eric_carlson, a major reason why the TF exists is to get info from pertinent authorities where ever they are (within/without W3C)

JS: Everyone needs to be heard, you don't need to be an authority to have a good ieea. We do hhave to work with the people who will make things work and we're casting about for a way to make that happen.

GJR: What we did is what EC suggested, we gathered opinions, vetted them and I think we're functioning in the way we should be.

JS: We need to try and keep that technically focused.

PC: The poll closes on 31/03/2011.

Sub group updates: Media

JS: Very solid progress is being made, however it's not possible to reduce the number of change proposals this week. It's going to take more time, and there was concern about this yesterday on the call.

<paulc> The Chairs have read the Media sub-group minutes in detail, we are monitoring the progress, we are processing MSFT's request for a delay in the survey, ...

JF: Issue 152 - There's still a lot of discussion happening, we're trying to get it done ASAP, and there is a concern that if it gets pushed too far we'll be missing a technical requirement that's been articulated early on. There's a general consensus, and we need this going into last call.
... There are a couple of other oustanding issues that we didn't get a chance to discuss, but none are considered critical at this stage.

<paulc> The WG Chairs will be meeting today after the WG Weekly meeting to discuss how to move ISUE-152 forward.

JS: The group remains focused via email, the wki and other channels in addition to the weekly telecons.

<JF> thanks paul

<paulc> I personally do NOT believe the survey will start on April 1 as originally announced.

PC: Keep working on the work you've been doing, I think it's heading in the right direction.

<paulc> Thank for all the great work on -152. We are in a MUCH better place than say a month ago.

JF: We're working hard to get this cleared up ASAP.

PC: Having a deadline for issue 152 seems to have helped.

longdesc

<paulc> Question for participants: would it have been better if I had NOT attended this meeting? You might have go more work done WITHOUT me?

<oedipus> paulc, no we DO appreciate your participation and are thankful for it

JS: We're looking to SF to help draft a proposal based on conversations at the F2F. LC has done great work, but calling it a change proposal is difficult because it seems to transmute several times a day at the moment and we need to extract a solid core from it.

<oedipus> change proposal strategy note: once the change proposal has reached maturity, any additional information pertinent to the issue should be logged using the wiki page's "discussion" page feature, so as to maintain the stability of the actual CP

<JF> +1 to GJR

GJR: Strategy note, once you have a change proposal you feel is close, it helps to log notes and comments on the wki. This helps the change proposal itself stay more consistent.

<oedipus> LauraC's original CP: http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

JF: The most important take away from the F2F was a relaxing of the stand on whether the presence of a longer description mechanism should be visible to sighted people. In listening to a lot of feedback and discussing it, there was agreement that having a visual indicator was useful though.

<oedipus> CP from SD F2F: http://www.w3.org/html/wg/wiki/ChangeProposals/imagedescription

JF: There was also some draft text put into SF's alt text document. Personally I feel this is the best place for author guidance.

JS: There is a whole question around the idea of a visual indicator or the ability to access that meta data via the browser. The response seems to be that there isn't an objection to this, but it's not strictly an a11y issue.

JF: The general feeling was that it would be a "should" requirement, rather than a "must" requirement. The belief is that the single widest barrier to the adoption of longdesc to date is that browsers haven't been able to convey the presence of a longdesc to users and this is why it's been broken.

<oedipus> note: PFWG has formally submitted its recommendation/resolution on Verbose Descriptor Requirements http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Requirements

<oedipus> 1. A programmatic mechanism to reference a specific set of structured content, either internal or external to the document containing the described image.

<oedipus> 2. A way to inform users and authors that a description is present/available.

<oedipus> 3. A device independent way to access the descriptive content.

<oedipus> 4. An explicit provision that accessing descriptive content, whether internal or external to the document containing the image, does NOT take the user away from the user's position in the document containing the image where the verbose descriptor was invoked;

JS: In a parallel effort, PF in response to this discussion and specifically in response to many f the issues raised during the first round of consideration, have tried to come up with a set of requirements.

<oedipus> 5. A way to provide user control over exposition of the descriptor so that rendering of the image and its description is not an either/or proposition. (A visual indicator of the description should NOT be a forced visual encumbrance on sighted users by default).

<oedipus> 6. A method to reference a longer description of an image, without including the content in the main flow of a page.

<oedipus> 7. Since an img element may be within the content of an a element, the user agent's mechanism in the user interface for accessing the verbose descriptor resource of the former must be different than the mechanism for accessing the href resource of the latter.

GJR: These requirements are attribute and element agnostic. These are specifically to define what functionality is needed for a verbose description mechanism. They're not requirements for longdesc specifically.

JS: The aim is for the TF to look at these and either modify or endorse them.

<oedipus> the 7 PFWG requirements for verbose description also logged as HTML WG Bug 10853 HTML5 lacks a verbose description mechanism: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

JB: Would it be possible for SF and JF to take a look at this before Friday, so the TF could look at it and see if we can get consensus?

JF: SF and I talked about this, and yes. There is some work that's happening and it's a mirror of what Laura is doing, and we want to make sure we capture the consensus we arrived at in San Diego.

JB: Can the TF confirm a welcome to Laura to coordinate directly with the TF on this?.

rrsagent make minutes

- DRAFT -

HTML Accessibility Task Force Teleconference

31 Mar 2011

Attendees

Contents

Canvas subteam update

Sub group updates: Media

longdesc

Summary of Action Items

Scribe.perl diagnostic output