Subteam reports

LeonieWatson: next bug-triage subteam meeting is Tuesday

canvas subteam

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

Text-alternative subteam

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