Minutes: HTML A11Y Text Alternatives Sub-Group Teleconference June 6. 2011


The Minutes from today's teleconference call can be found here:

...or in plain text immediately after this announcement. As is always the
case, corrections and comments should be posted to this list.



HTML A11Y Text Alternatives Sub-Group Teleconference
06 Jun 2011

See also: IRC log (http://www.w3.org/2011/06/06-text-irc)

    Judy_Brewer, Léonie_Watson, Michael_Cooper, John_Foliot, Geoff_Freed,
Marco_Ranon, Janina_Sajka, Lynn_Holdsworth, Steve_Faulkner


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

<scribe> 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

<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
... 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

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

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

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
... 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

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.


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

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

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

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.
Summary of Action Items
[NEW] 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]

[End of minutes]

Received on Monday, 6 June 2011 16:55:27 UTC