Re: SVG AAM

Hi Fred,

I never properly replied to your review; thank you for being so thorough.
See comments on each point below.

I've made a few corresponding changes to my fork of the spec:
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html

We can discuss on Friday & determine if further changes need to be made.

~Amelia

On 28 October 2015 at 13:06, Fred Esch <fesch@us.ibm.com> wrote:
>
>
> *General Comment*
> Where ever *xlink:href* is used can we mark it deprecated?
>
We should probably mention it somewhere, but I don't know if we need to
over-emphasize.  After all, this spec is aimed at user agent implementers,
and we still want to clearly instruct user agents to handle xlink:href
correctly.  That said, we need to emphasize that the href attribute takes
precedence if both are present, in accordance with SVG 2.

I've added a paragraph to the attributes-processing section more clearly
explaining the situation with XLink attributes.


> *Section Status of this Document*
> *Comments are requested by** 27 March 2015**. * We are past this date.
>

This is the date from the FPWD.  When we have a date for publication of the
new draft, we will know what date to put in its place.  I highlighted it
explicitly so it would not get overlooked!

> *Section Important terms *
> Hidden has a editors note asking whether it needs a new definition. We
> could use Amelia's definition from section *5.1.1 Excluding Elements from
> the Accessibility Tree*
>
> Hidden
> Indicates that the element is neither visible nor interactive and
> therefore not perceivable to visual users.
>
That sounds good to me, but it needs to be brought up with the main ARIA
team.  These definitions are all being imported from a common set used by
all ARIA specs.


> *Use element issues*
> *Section 5.1.1 Excluding Elements from the Accessibility Tree*
> Second paragraph after first note.
> *For example, elements that represent filters, gradients, or gradient
> stops will never create an accessible object. Shape elements or image
> elements that are included in an SVG definitions section or as part of a
> pattern will also not have accessible objects, because the semantics of the
> ancestor **defs **or pattern element preclude that entire DOM subtree
> from being represented in the accessibility tree. *
>
> I believe we should remove defs from the last sentence and/or provide an
> explanation of what happens with the *use *element, SVG shadowDOM and the
> accessibility tree.
>
I would not want to remove the reference to <defs> altogether.  There may
be content in a <defs> block that isn't used at all, it's just there to be
accessed by scripts or something similar.

If we do require the accessible tree to represent the shadow DOM of <use>
content, it would be that visible cloned copy that is represented in the
tree, not the original definitions, so I don't think this sentence is
problematic.


> *Section 5.1.2 Including Elements in the Accessibility Tree*
> mentions *elements that are interactive elements **MUST** be included in
> the accessibility tree*, but interactive elements from* use* element
> references are not explained.
>
The <use> element itself, if interactive, is included in the accessibility
tree.  The cloned sub-components are not elements (at least as far as SVG
1.1 implementation).  If SVG 2 goes with a shadow-DOM based implementation,
and/or if we require cloned content to be directly accessible, then we will
need a detailed description of how to represent those elements in the
accessibility tree.

For the time being, I've added an extra sentence to the final paragraph (re
elements which are themselves hidden but have child content that is not) to
clarify that it applies to use elements as well.


> *Section 8.2 SVG Element Mapping Table*
> An editors note in the *use* element in indicates that there are open
> issues with the use element.
>
 Yes, that's really the biggest issue we need feedback on.  As you've
noted, there are lots of corresponding changes that will be required if we
take a different approach.

> *10.1 Name and Description*
> *Editor's Note Example 1 *
> has xlink:href (deprecated) should replace with href
>
Changes.  Old habits die hard.  (Especially since href doesn't actually
work most places, yet!)


> *10.5 SVG Views*
> Is viewTarget is being removed in SVG 2? If so, should it be mentioned in
> this section?
> *https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG*
> <https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG>
> Section 15.3.3 Predefined views: the 'view' element
> Annotation 1
> *We have resolved to remove viewTarget attribute.*
> *Resolution: Paris 2015 F2F Day 3.*
> *Owner: BogdanBrinza*.
>
I've added an Editor's Note to our spec, and I am following up with the SVG
working group to try to get this decision reversed.