SVG A11y TF meeting -- 05 Jun 2015

<fesch> https://www.w3.org/wiki/SVG_Accessibility/Navigation#Amelia.27s_Proposal_.26_Related_Brainstorming

<cpandhi> Can you hear me

<use> element clones

<shepazu> be right there

<fesch> https://www.w3.org/wiki/ARIA_roles_for_graphics

ABR: The <use> element creates a copy of an original graphic. It's used a lot with the <symbol> element.
... Browsers treat <use> as atoic - they don't look at the copy. Firefox may be the exception.

FE: If you put <title> inside <symbol>, the title is never shown.

ABR: Yes, so accessibility in the original content is not transferred to the cloned copy.
... So the question is whether the accessibility tree of the original content be cloned as well?
... There are instances where you would want the acc tree to be cloned - like a <symbol> that's reused frequently. There are times when you wouldn't - like <text> duplicated for shadow effect or similar.
... We could access the acc tree with ARIA though.
... Perhaps aria-owns, except it should only be for a single parent.

FE: Single inheritance as opposed to multiple inheritance.

LW: Sounds like the acc tree clone for <use> is something we need to address, irrespective of the icon v symbol conversation?

ABR: Yes. We'll need to look at how/when the acc tree is cloned.
... Wonder if people want to think on this for a bit?

LW: Yes, good idea.

DS: I prefer not to think about stuff too much, better to put something out for review.
... Let's go ahead and resolve.

ABR: We can use aria-describedby to associate the original <desc> with the clone.
... the element you're copying will have the id.

FE: Why wouldn't you directly inherit the atomic behaviour of the element being inherited - like <symbol>?

LW: What about a boolean attribute that tells the browser whether to clone the acc tree or not?

ABR: We could make it role based.

FE: Like group with children, or one child?

JW: A screen reader might not play well with a group role with a single child.

ABR: If the SVg doesn't have <title> or <desc> it would map to role="none". It would be transparent for accessibility purposes.

FE: That sounds like desireable behaviour.
... ,use> is just a pointer. So unless you say it's presentation only, the <use> itself doesn't add anything itself.

ABR: Recap... we want the browser to copy the acc tree of the cloned content.
... The <use> element would behave as an SVG group, where it would only have a specific role if it contained acc content.

FE: You could assign it a presentation role, so it does nothing.

DS: Not convinced that's a good idea.

ABR: Which part?

DS: It's technically possible to do this, in most cases <use> is just an atomic symbol.

FE: YOu can reference anything using <use> though?

DS: Yes.
... and you could have something that says "pay attention to this thing", but that should not be the default.

LW: That's why I was thinking about an explicit way of informing the browser it needed to inherit the acc tree.

ABR: To make the default case easier, we could say if there was a <title> or <desc> that was carried through.

FE: <use> doesn't need to be an extra layer.
... Unless you explicitly add stuff.

ABR: It's one or the other. You don't want a couble layer, but if the <use> has the same title/desc as the copied content, for the acc tree that should have the same effect.
... current practice is that the title/desc have to go on the <use>, because the browsers don't clone them automatically.

FE: If you have a decision tree, with text/labels inside symbols. Can't label the symbol itself, because you can't then replicate the symbol.
... so you add the label through the <use>.

DS: Don't follow.

FE: A decision tree has symbols.
... Symbols inside nodes will often be text.
... You can't associate the label with the symbol, because the symbol will be reused (potentially with different labels).
... So the label has to be applied with the <use> element, not the <symbol> element.

DS: Doesn't presentational mean it's ignored completely?

ABR: It means that element is ignored, but not child elements.

DS: The fact you're using a symbol is meaningful.

FE: You're right.

DS: So I don't think this is a good use case. Most times I've seen <use> used, the thing is not presentational.

LW: If <use> can be used to clone any kind of content, we need to cater for any degree of accessiblity inheritance.

DS: Would argue there are better ways to use <use> than to clone complex content.
... Think we should inherit the <title> and <desc> of the original, and leave it there.

ABR: So there should be a direct aria-labelledby and aria-describedby relationship, but we wouldn't copiy the entire acc tree.

DS: Strikes me as the right balance.

LW: Concern is that although Doug is right about the way <use> should be used, is that what developers are actually doing out there?

ABR: The capabilities aren't really there in browsers to support it anyway, so I don't think it happens much.

DS: Don't think any script libraries do it either.

FE: You could use nested <use> elements right?

ABR: Yes.
... That's a real use case - constructing complex symbols using multiple individual symbols.

DS: You'd want the composite information in the description.

<AmeliaBR> Proposed Resolution: A <use> element has an implicite labelledby & describedby relationship with the element it is re-using, but there is no clone of the accessibility tree

JW: I have an issue about whether something has children that should be included in the acc tree as part of its acc role.

ABR: We're saying you'd never clone the acc tree through <use>, so there would never be children.
... Implementors will like this because it negates the need for code to clone the acc tree.
... It just extends the acc name/desc computation.
... YOu can give it a role, but it'll never have child elements.

JW: Want someone to establish whether there are any counter examples to this proposal.

ABR: A <use> element never has children in the DOM that will be in the acc tree, other than <title> and <desc>. Question is whether we should clone the visual children in the acc tree.
... It is simpler not to. We don't have use cases to justify that extra complexity.

JW: But if you need to be able to navigate/interact with the content, not in UI sense, but navigation/reading sense, then there needs to be an acc tree.

DS: The whole point of <use> - in a visual/graphical sense, is that you don't drill down into it. So it's the same in a structural sense. So we're just expressing that at the acc layer.
... We're mimicing the experience for sighted users within the acc tree.

ABR: On a tangent, this isn't in the spec but... we could add an attribute on <use> so it becomes a proper clone. Like with HTML templates for Web Components.

LW: That's the idea I was thinking of earlier, but at the content level instead of just acc layer.

DS: Could just use the same semantics as HTML.

ABR: So that would cover those use cases when <use> isn't quite appropriate.

JW: That would satisfy my concerns.

RESOLUTION: A <use> element has an implicitlabelledby & describedby relationship with the element it is re-using, but there is no clone of the accessibility tree.

DS: Hearing no objections, the resolution passes.

- DRAFT -

SVG A11y TF meeting

05 Jun 2015

Attendees

Contents

<use> element clones

Summary of Action Items

Scribe.perl diagnostic output