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?

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.

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