Re: figure role backgrounds

> so that you can add all of HTML.

To clarify, again:

No, you cannot currently add arbitrary HTML elements to SVG.  There are
only a very limited number of metadata and embedded content HTML elements
that have been allowed.  Metadata are fine because they don't affect
rendering.  For the embedded content elements, we created new rules for how
they interact with SVG layout, based on SVG <image> and <foreignObject>
elements.   The SVG-AAM already refers to HTML-AAM for the HTML embedded
content elements that are allowed in SVG.

Any other HTML element (and all its child content, SVG or not) would not
render, even if it is parsed to the correct element type thanks to XML
namespaces.  In an HTML parser, it would either be assigned the wrong
namespace or be treated as a parser error, causing immediate closing of the
open SVG elements.

Changing the rendering rules would require considerable re-writing of how
CSS, HTML, and SVG interact.  It may happen in the future, but we're
nowhere near that now.

Using roles to assign semantics to SVG content is a progressive enhancement
that doesn't affect the rendering of the SVG in non-browser user agents, or
in existing browsers.

Using roles that directly map to existing HTML semantics should ensure that
they are easy to spec, easy to implement for user agents and ATs, easy to
remember for authors, and (hopefully) easier to understand for end users.

A <g role="figure"> will be laid out and rendered like any other SVG <g>,
but would be exposed to accessibility APIs like an HTML <figure>.

~ABR

On 15 September 2016 at 21:15, Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> Anne, I had not been to the SVG working group meetings of late as the
> meetings were scheduled at a time I could not attend. I see the group made
> a significant change here in that it went back to using namespaces for HTML
> features like Iframe so that you can add all of HTML.
>
> Regardless, it is a lot easier for the author to add a role than to add a
> namespace for HTML and a prefixed HTML figure element when all you want is
> the role semantics. ARIA initially had namespaced role values and they were
> not favored by browser community. We should probably add something to the
> SVG accessibility API mapping spec. to refer to the HTML AAM for those
> namespaced elements.
>
> The accessibility people want to use semantics consistently across host
> languages.
>
> There is a place for both.
>
> Rich
>
> Sent from my iPad
>
> On Sep 14, 2016, at 3:45 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> >> The SVG accessibility effort does not want to piece part chunks of host
> language elements in the middle of an SVG document which needs to stand
> alone. Not all SVG documents are embedded in HTML. So, sticking an HTML
> figure element inside of an SVG document is a non-starter.
> >
> > This seems diametrically opposed to the efforts of the SVG WG, who no
> > longer wish to duplicate HTML efforts and are working on making it
> > easier to use both together. I don't understand why the SVG
> > accessibility effort would chose a different direction from the SVG
> > WG.
> >
> > (Sorry if this email breaks threading. I'm not subscribed and the
> > mailto URLs on the mailing list archives may or may not have done the
> > trick.)
> >
> >
> > --
> > https://annevankesteren.nl/
>
>