Re: semantic level of SVG usage

--485b395e78b79294a5053a5aeffb
Content-Type: text/plain; charset=UTF-8

Regarding Jonathan Cohn's question:

Is the labeling of SVG supported by the primary screen readers at this
> time? Would your proposal mean that all screen readers would need to
> implement a second approach to providing information?
>

At this time, screen reader support of SVG is limited, but it has been
getting much better in the past year, primarily because of improvements in
the way the browsers expose the document.

What we had seen previously was that browsers tended to expose ARIA
attributes on SVG elements, but not SVG's native alternative text elements
(which use child text-container elements to describe the parent graphic
element).  SVG 2 and SVG-AAM now require both types of alternative text to
be supported, with the ARIA attributes taking precedence when they are
present.  Therefore, any graphic that was made accessible through the
addition of ARIA attributes will remain accessible in the same way.

But in addition, we expect to see an improvement in accessibility of many
graphics which included alternative text consistent with the SVG 1 model,
but which weren't being correctly exposed to assistive tech.  Furthermore,
because SVG 1 used a child element for alternative text, instead of an
attribute, SVG 2 was able to define multiple alternatives in different
languages.

At the screen reader level, there should be no change in implementations:
the differences would be handled at the browser level, in how they compute
the accessible name and description for the shape elements.

Once the browsers get better at exposing SVG documents in a consistent
manner, then more advanced screen reader features may be possible, allowing
two-dimensional exploration of the graphic.  This could be especially
useful once more complex semantics are defined for data charts, maps, and
flow charts.  Some demonstration software exists showing how this could
work, but the interaction is controlled entirely with scripting, rather
than using native screen reader features, so we do not have to worry about
backwards compatibility.

~Amelia Bellamy-Royds

--485b395e78b79294a5053a5aeffb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Regarding Jonathan Cohn&#39;s question:<div><br><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">Is the labeling of SVG supported by the primary screen r=
eaders at this time? Would your proposal mean that all screen readers would=
 need to implement a second approach to providing information?<br></blockqu=
ote><div><br></div><div>At this time, screen reader support of SVG is limit=
ed, but it has been getting much better in the past year, primarily because=
 of improvements in the way the browsers expose the document.</div><div><br=
></div><div>What we had seen previously was that browsers tended to expose =
ARIA attributes on SVG elements, but not SVG&#39;s native alternative text =
elements (which use child text-container elements to describe the parent gr=
aphic element).=C2=A0 SVG 2 and SVG-AAM now require both types of alternati=
ve text to be supported, with the ARIA attributes taking precedence when th=
ey are present.=C2=A0 Therefore, any graphic that was made accessible throu=
gh the addition of ARIA attributes will remain accessible in the same way. =
=C2=A0</div><div><br></div><div>But in addition, we expect to see an improv=
ement in accessibility of many graphics which included alternative text con=
sistent with the SVG 1 model, but which weren&#39;t being correctly exposed=
 to assistive tech.=C2=A0 Furthermore, because SVG 1 used a child element f=
or alternative text, instead of an attribute, SVG 2 was able to define mult=
iple alternatives in different languages.</div><div><br></div><div>At the s=
creen reader level, there should be no change in implementations: the diffe=
rences would be handled at the browser level, in how they compute the acces=
sible name and description for the shape elements.</div><div><br></div><div=
>Once the browsers get better at exposing SVG documents in a consistent man=
ner, then more advanced screen reader features may be possible, allowing tw=
o-dimensional exploration of the graphic.=C2=A0 This could be especially us=
eful once more complex semantics are defined for data charts, maps, and flo=
w charts.=C2=A0 Some demonstration software exists showing how this could w=
ork, but the interaction is controlled entirely with scripting, rather than=
 using native screen reader features, so we do not have to worry about back=
wards compatibility.</div><div><br></div><div>~Amelia Bellamy-Royds</div><d=
iv><br></div></div></div></div></div>

--485b395e78b79294a5053a5aeffb--