<Leonie> scribe: Leonie

Reminder WG schedule http://lists.w3.org/Archives/Public/public-html/2011May/0162.html to monitor during Last Call

JB: LC was issued on 25th May. They need bugs filed by LC.

JF: There were a couple of issues that have results published on, for example alt text. If we want to open again with new info, it has to be done by then.

JB: Is that the same for bugs?

JF: I'm guessing yes.

JB: Since the chairs issued a call for alternative proposals, we have a three week period in which people can submit counter proposals. One person preannounced they would be doing this.
... It would be useful to look at this and anticipate our response, rather than wait until there are multiple change proposals around.

JF: My understanding is that Jonas said he would have a counter proposal by 25th June. If I understand what he wrote, he'd like to require that aria-describedby remains HTML rich.
... At the moment the browsers are flattening the value into text. Jonas is proposing that the text it points to should remain HTML rich.

JB: There's a few different possibilities for how we proceed. One would be to engage directly with Jonas on the list, and say here are our concerns about things we would not expect your proposal could address.
... That could be a good way to go. Another approach would be to make sure the proposal this group supports explains why an alternative proposal probably wouldn't work.
... The issue there is that people wouldn't see it, unless they went to look at it specifically. People could read Jonas' idea without having the background.

<JF> +q

JF: We're in a strange situation. The bottom line is that we want aria-describedby to do this. We have a similar situation with the discussion over video/poster alt.
... One on hand I want to encourage Jonas putting this forward, but we also need to ensure that the browsers implement it. I think they'll only do that if the feedback from the community is that it's the right thing to do.
... In terms of this being a fully functional replacement for longdesc, it can't be a legacy/backwards compatible solution.

JB: One possibility would be a qualified response that this is a direction that may be useful n the future, but we don't think it fully addresses the user requirements. Perhaps we should invite him to the discussions?

SF: In regard to understanding how aria-describedby is supported... Across all browsers, it takes the text content of the element with the associated id ref and puts into what's generically known as a description.

<janina> I think Steve is saying in detail what John was saying in general.

SF: What Firefox also does... in iAccessible2 there is a way to create a relationship between the two things. iAccessible2 isn't in IE, it is in Chrome... It isn't currently picked uh by screen readers.
... I don't think the approach is practically helpful. I think we should continue the discussion on list though. It's the most open and productive approach. These things do need to be better explained though.
... aria-describedby has always been pushed, not nescessarily by the a11y community, but by others as being only to do with the accessibility layer. That browsers shouldn't provide any non AT related support foR arARIA.
... As long as aria-describedby is just for the AT layer, there are other people with disabilities who don't use ATs who will miss out.

<JF> +q

JB: It doesn't make sense to me for us to wait until 26th June for his proposal, if it doesn't address the things it needs to.

JF: Steve, perhaps you and I could co-author a response to Jonas?

SF: Sure, yes.

JF: I want to encourage Jonas to continue advocating this approach. Even though it won't solve longdesc, it will solve other problems.

JB: Let's not let this sit. Could you get something together later this week?

SF: Yes.

<JF> ACTION: JF and Stevef to work on drafting a response to Jonas [recorded in http://www.w3.org/2011/06/06-text-minutes.html#action01]

JB: The other part of this, is whethere there are any edit requests for our/Laura's change proposal. There was one particular sentence that several people flagged. It wasn't favourable towards ARIA. I think it's been edited though.
... It may be there are other parts of the change proposal that are not favourable towards the evolution of ARIA.
... Does anyone on the call have comments?

JF: I think some of the additional comments were from Silvia, and that Laura has incorporated them now.
... This is my concern, that the change proposal keeps changing.

JB: Laura froze it when we voted on it, then after the LC doc went forward we asked her to open it up again to make those changes.
... Whilst the call for counter proposals is out, we have the opportunity to further refine our change proposal.
... If there are any additional change proposals that come in, there may be aspects of Laura's change proposal we want to edit to respond.
... For the alt and title... For title we still have the option to have a meeting to see whther any final clarifications are needed, but as far as I know the work is done.
... What is the status of metaname generator?

JF: Leif submitted a change proposal. It captures the issue well, but could do with some refinement.

SF: I'd be able to help with this one.

JB: How long do you think this would need in terms of cycles? I'm looking at the 5th July bug deadline, which means the week before in terms of our response.

SF: If we submit a change proposal, the chairs would then need to issue a call for counter proposals.

JB: I just want to make sure our proposal isn't open to fail.

JF: My concern right now is that we've identified 2/3 issues with that issue 80respose... Have we escalated these things to issues?

JB: Formally? No, I don't think we have.

JF: If we don't setup that scenario, what are we submitting change proposals against?

JB: When we spoke about this before, I think we agreed to split things out.
... It sounded as though there were one/two possibilities that the composite decisions could be combined when they went in. If we haven't split them out yet, it may make sense to wait a week or so before we do.

JF: I don't understand why we'd want to delay?

SF: The thing with not splitting them, is that if two are together and one is rejected, both are rejected.

JB: Does anyone object to formalising that split out?

SF: No

JB: Does anyone object to doing the split on the call?

No objections.

SF: What does that mean exactly?

JF: We need to identify the things we disagree with, and file bugs on those individual things.

SF: I thought we'd already done this for alt title?
... So we need to make a request to open the rest as individual issues?

JB: We're talking about formalising the split out of the six different issues, and we want to split out the ones we want to respond to.
... Michael, could you take care of the split?

MC: I'm not sure I understand the task.

JF: Could we go to the chairs and ask them how they'd prefer to receive the formal response?

JB: We still need a volunteer though.

SF: Looking at the HTML5 spec, it has issue 80, and metaname generator as well.

JF: Does it have an issue number?

SF: Issue 31.

JF: Yes, but issue 31 contains other points and if we fail on one, we'll fail on all.

<Stevef> http://dev.w3.org/html5/status/new-information-status.html#ISSUE-031c

SF: They seem to be split out here.
... It probably just needs clarification from the chairs.

JB: I can follow up on this with Janina and Michael.
... John, with role=presentation, remind me of your next step.

JF: I don't think we have a problem with thi.

SF: Neither do I. I think Rich and Cynthia were going to talk about this.

JB: There are some multiple stages. Some were to be pursued as a bug... I'd need to check back to the minutes for more information.
... I don't have an opinion on role=presentation.

JS: There was a question about whether we should file a bug on a non emtpy string for role=presentation and whether it should be flagged for conformance.

s/non empty/empty/

JB: Figcaption...There has been a bit of back/forth on this. The status is... At one point we thought there was no information, then it go spread in three/four different directions.
... Is this something that should/could be handled through guidance, rather than through HTML5 directly?
... For instance, if you're doing a figure caption for a scientific publication and the caption has specific requirements (for example it must be 100 words long), then do you need an alt?

SF: I think we're talking at cross purposes. I don't think figcaption is a legit way to provide a text alternative. The best way to do this is alt. In situations where a text alternative has not been provided...
... In the context of the point in the HTML5 spec that says when an alternative for an image is not know, you can either use title or figcaption.

JB: I think that if it's for the purposes of identification, that might also be handled through guidance, but it could be open to abuse.

JF: If figcaption is present, in some ways it also quietens the validator in the same way that it does if role=presentation is there. It's going to say there is no alt text, but there is...
... We also need to think about practical outcomes here. This is the best solution to the Flickr use case.

SF: Yes.
... If it still says that we require an alt under any circumstance, it can not put an alt attrib in there at all, so in most circumstances screen readers won't pick it up at all, or it could put in an id ref that could be picked up by a screen reader, or give it a null value.
... Of the four, the scenario of having the figcaption announced is probably the best.
... Essentially, if we accept that the validation requirements for HTML are not going to require alt... they can't require a useful text description...

JF: If we insist that Flickr images must have an alt, they'll just double up the information that's part of the figcaption.
... It may not be a complete solution, but it is useful.

JB: Let's talk about the differences between the edge cases. For me the blind photographer example is an edge use case.
... It may be worth filing a bug to get that case removed.
... The flickr case is an edge case, but it's not the entire story on how images are used. The scientific publishing field is huge, and in that figure captions are not always things that would be useful as alt text descriptions.

JS: Could this influence the longdesc decision? Figcatpion may not be well enough defined?

JB: There are maybe three examples in the spec (at most).

JS: So maybe it's a bug against figcaption itself?

<JF> +q

JB: When considering the scientific use case, I almost wonder if there needs to be two different levels of figcaption?

JF: Judy hit the nail on the head when suggesting it could be handled through guidance. We have to presume there is a certain subject level expertise/understanding to ensure it meets requirements.
... If an institution publishing scientific data should refer to guidance on how to do that accessibly. If a figcaption is present, it has the net effect of invoking role=presentation on the image, with the advantage of saying here is some information on the image.

<JF> scribenick: JF

LW: figcaption is not picked up by SR

but tends to agree that it is the use-case

and insisting that @alt is there will just muddle things up

JS: believes this is how the discussion went in WAI WG

spent a lot of time talinjg about the Flikr use-case

<Leonie> JS: We spent a lot of time talking about the Flickr use case, but I don't recall we looked at the scientific publishig use case.

<Leonie> JB: I'm hoping we can come up with a solution that meets both use cases.

<Leonie> JS: So if figcaption doesn't differentiate, it's difficult from a conformance point of view to say whether it's appropriate.

<Leonie> JB: The intersection with longdesc is a concern...

<Leonie> JF: Backwards compatibility.

<Leonie> JB: That's a concern from the beginning. Do we need to respond separately about longdesc and figcaption?

<Leonie> JS: In their response on longdesc, the chairs mentioned figcaption as an alternative to longdesc.

<Leonie> JB: Do we need a response that separates out several different issues? One might be clarifications in relation to longdesc, then also noting for the record that there was a subjective evaluation of two speculative decisions, so it may beneed to restate some of the evidence?

?me

<Leonie> JF: They have different outcomes and different results, depending on how you use them. They all have practical outcomes, depending on how/where they're used.

JS: there is a question of measuring what is appropriate when

JB: if there was a link heuristic, then that could be a level of conformance
... motivated to take a fairly different pass on this

completely different way of looking

does anyone disagree with trying

JB: think we are almost finished

can we identify a scribe for next week?

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/towards ARIA/towards the evolution of ARIA/
FAILED: s/non empty/empty/
Found Scribe: Leonie
Inferring ScribeNick: Leonie
WARNING: No scribe lines found matching previous ScribeNick pattern: <JF> ...
Found ScribeNick: JF
ScribeNicks: JF, Leonie
Present: Judy_Brewer Léonie_Watson Michael_Cooper John_Foliot Geoff_Freed Marco_Ranon Janina_Sajka Lynn_Holdsworth Steve_Faulkner
Got date from IRC log name: 06 Jun 2011
Guessing minutes URL: http://www.w3.org/2011/06/06-text-minutes.html
People with action items: jf stevef

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