See also: IRC log
LeonieWatson: next bug-triage subteam meeting is Tuesday
richardschwerdtfe: have a draft of focus
management, text baseline
... Charles Pritchard helping
... have most of the CP written. Next is clickable regions
... based on feedback from Maciej, waiting for clickable regions
Cynthia: when will the focus-management writeup be ready?
richardschwerdtfe: waiting on Charles for that
... we're reusing the same names that Hixie had originally
... slight difference in API calls
... but fairly close
Cynthia: if you can forward something to me, I will pass it on
Judy: teleconference resumed this Monday
... had a hiatus during end of LC
... we rediscussed approach around, e.g., discoverability
... I hoping we will see a response from John Foliot before he heads away for
vacation
... idea is to have dialog on the counterproposal from Jonas and see how far
we get with that, have a dialog before the chairs proceed with survey
... next we took up meta@name=generator
... next step on that is for janina, and we need to get the TF feedback on
writeup from Steve Faulkner
... next meeting is next Monday
... we discussed feedback on the bug that was filed during LC, about
refinement on conformance assessment, concern about overly-long figcaption
case
... we asked a few people to get some evidence on the amount of problems with
figcaptions of different lengths
... some of the respondents on the bug were not aware of the UX around
figcaption
... we had at some point considered having another subteam to discuss the TF
decision policy and the HTML WG decision policy
Stevef: question about the length of
figcaption... I think this question is at least partially relies on the way
figcaption will be implemented
... if it's implemented as the accessible title for the image, then it's going
to be a long string
... if it's implemented differently, then the UX will be differnt
... issue is, figure and figcaption are not exclusively about images, and a
figure can have multiple images
... figure could also have, say, code in it, or a poem
... so the role depends on what the content of the figure is
... wondering how implementors are going to see this
Stevef: also, figcaption is not a simple attribute, it's an element, it can have character formatting -- so stuffing that into an accessible name [may not be best]
Cynthia: after Sep. 7, let's set up a meeting
Judy: Stevef, I'm interested in what you're
saying, because in looking at various examples of figcaption, I notice that in
certain kinds of publications, you get types of figure captions that are very
different from simple phrases you see in a photo album or whatever
... one of the things that got interesting was looking at some of the trends
on publishing
... where you have a sort-of two-tier caption
... and it becomes complicated to figure out how to deal with those, and the
current spec does not do that well yet
... there is a key piece of conformance that's not covered in the spec yet
JF: we have been working from the assumption that figcaption could be a viable stand-in for the image
<Judy> Judy: and there also multiple instances of composite images in figure captions that need to be dealt with appropriately
JF: I am almost at the point of why we are pursuing this, why we should not just say that figcaption is not an alternative, and move on
richardschwerdtfe: it's just not an alt
... we are already providing mappings for these types of relationships
Judy: when I started first looking at the
decision that had come in, I thought it was wrong, and I continue to be
concerned that we have no assurance that screen-readers are going to handle
backwards compatibility over a multi-year transition
... Geoff Freed has also been questioning, wondering if we just made the wrong
call on this
Judy: my take after looking at a lot of figure captions is that a lot of them are appropriately brief and appropriately relevant, but that there are number of cases out there that are not
Stevef: the content of the figure can be more
than images -- e.g., a poem -- not that the figcaption content can be a poem or
whatever
... having a figcaption does not mean it's accessible
... for case of figcaptions in scientific journals, obviously if you have a
large piece of text with structure in it, you don't want that to be conveyed
just as flat text
... we need to make sure that we are providing the best experience for the
user
Cynthia: I think we may be asking too much about
HTML conformance -- there are some subtle judgements that make more sense have
for WCAG testing
... and we may be trying to put too much nuance and subtlety into HTML
conformance
... a lot of IDEs also now have a11y validation
... we may want to think about separately it out
Stevef: we cannot just using HTML conformance be able to tell, unless we look at it
richardschwerdtfe: yeah, we can put the
requirement into WCAG checking
... I don't think we want to look for a character limit.. AT is going to look
at it, as an element
... you can require a label or a title on it
... you could have an implied role of image
... you still have the structural elements in there
... we have a similar role in ARIA that wraps a set of images
... kind of like describing a set of powerpoint slides, as a set
... I agree with Stevef that you don't want to remove the markup in there and
just convert it into a string
... I don't think it makes much sent to try to put a length limit on it
<richardschwerdtfe> you have aria-label
<richardschwerdtfe> you don't need alt
JF: problem is, while I agree that we don't want
to try to rely on HTML conformance to do WCAG conformance
... but you can have an image with zero alt-text, bug a figcaption, then it's
going to pass HTML conformance
Stevef: most AT ignore images without an alt
... so they won't announce an image is there
JF: the thing is, I am prepared to go with the
crowd (though that might not be the best way to say it)
... but I am concerned that we are opening the door to poorer UX for this
Judy: so the current spec says that missing alt
is conforming in the face of figcaption, period.
... maybe a minor adjustment would be throwing up a warning instead
... and that is something that may make sense in balancing between HTML
conformance and WCAG conformance
... Cynthia, I hear what you are saying about that, and I am looking forward
to the further discussions about that
... the backwards-compatibility, if everyone says that could be convincingly
addressed, and we knew what the UX should be when you get his with a barrage of
text, then we can move ahead
Cynthia: I think we are making a mistake that we have made before, about letting AT off the hook
<Judy> Judy:...in terms of the backwards compatibility issue; and also also we need more info on the user experience.
Cynthia: just because there are AT that are not
going to know what figcaption is, that doesn't make them right [for not
supporting it]
... could have WCAG require a warning like "browsers and AT combinations prior
to 2012 might not handle this correctly"
richardschwerdtfe: we have one AT vendor that
uses two different sets of APIs
... we need to understand that if we are trying to support old-old-old ATs, we
need to [be realistic about that]
... regardless of what the HTML spec says, We can make requirements in WCAG
... I don't think this is a big issue
... relying on the HTML spec for a11y, well, we should not get hung up on
that
Judy: richardschwerdtfe, I think we need to be
careful about belittling the backward-compatibility issue
... this is not just about "old-old-old" ATs -- the backward-compat issue is
with current AT that are in use now
... I think it's still important to get the HTML spec to say the right
thing
Stevef: the sorts of scenarios where figcaption
would be a standin for the alt is when the author does not or cannot provide an
alt
... it doesn't mean it's automatically accessible
... we need to consider the case where it's _likely_ to be used
... putting something that's not really a text alternative, but instead is a
description, that is very bad UX
... using the right container for the right thing is what gives the better
UX
JF: but you can run into a case where the user ends up getting a description of something that's out of the flow, that's been skipped over
Stevef: in this situation, the text alternative
is not being provided in the first place
... this is why figcaption is a step forward, because once implemented, it can
tell the user that it's an actual description
<JF> +1 to Judy
richardschwerdtfe: yeah, the AT can automatically know that it's a caption for this thing, and that's really powerful
Cynthia: John, I think you are making the mistake of thinking that AT are not changeable, and letting them off the hook
Judy: I support the idea of being able to guide
AT
... if we are trying to make sure that it's eventually good practice, we have
the wherewithal to help shape that
... Stevef, from your comments, it sounds like you are looking a very specific
case, but that way the current HTML spec handles this is a blanket approach
<Judy> judy welcomes the discussion on this topic and invites people over to the text alternatives sub-group on monday for more -- thanks!
Stevef: If I am here, I'll do it (but I can't promise I'll do it)
Marco_Ranon also says he can if he's actually on
adjourned