Re: figure role backgrounds

Hi Alexander,

A little more detail on what Richard said…

The figure role came from the SVG Accessibility task force, when we were
trying to identify the "missing roles" for describing graphics in web
pages.  The fact that <figure> already existed in HTML was seen as a reason
*for*, rather than a reason against, adding a corresponding role to ARIA.
We wanted non-HTML documents to also be able to expose those semantics.

ARIA is not merely an extension to HTML.  ARIA is (supposed to be) a
complete language for describing the semantics of internet applications and
web documents.  Although limitations of HTML, relative to native
applications, were a driving force for the original creation of ARIA, that
shouldn't be the end of it.

ARIA is available to be used in any XML syntax, including SVG and ePub.
Ideally, other XML formats (such as those used for office documents) would
also adopt ARIA mappings, so that software could leverage the existing role
mappings, and assistive tech could give users a consistent experience,
whether they are viewing content in a web browser or in a native

We're a long way from that still.  There are many semantic features of HTML
which have defined mappings in the operating system accessibility APIs but
which can't be described yet in ARIA.  (For examples, just look at all the
custom mappings in the HTML-AAM
 And that doesn't even cover all the semantic nuances described in the HTML
specs for which the accessibility APIs don't have equivalents, including
such important distinctions as <code>, <ins>, and <del>.  I would very much
like to see ARIA equivalents for *every* HTML semantic element in ARIA 2,
and I know that's a planned topic of discussion for web components / custom
elements accessibility.

Going back to the specifics of the figure role, and why we thought it was

Figures, and figure-like objects such as tables and equations, are often
referenced by name and number.  In both print and web layouts, their
position in the display may be constrained by practical considerations, so
that they aren't immediately adjacent to the relevant prose.   Ideally on
the web, any references to a figure or table would include a cross-link,
but that doesn't always happen when content originally made for print gets
adapted for the web.  Even if it does happen, a link on its own doesn't
make it easy for non-visual users to skim through and find the figures.

Some screen readers offer users a way to jump to images, just like they
jump to links or headings. But that is currently imperfect, since there may
be lots of minor images (e.g., icons) on the page, and since some figures
may not be graphics (e.g., math equations, code samples), or may be
graphics marked up in a way that doesn't get recognized as role=img (e.g.,
inline SVG, video, flash objects).

The figure role therefore:

   - indicates that the region is a self-contained figure including its
   captions, and software may safely re-position it out of the flow of the
   text (but, unlike a complementary region, it is still an essential part of
   the main text or article, and wouldn't normally be omitted or published

   - indicates that users would benefit from a way of easily finding this
   content (either because they are following un-linked cross references from
   the main text, or because they are scanning for the major landmarks in the

As you note, currently browsers and ATs do not generate proper figure lists
based on HTML figure elements. So adding a figure role is only the first
step.  The next step is trying to get traction on the part of the role
description that states "Assistive technologies should enable users to
quickly navigate to figures."

The other purpose of the role is the one particularly important for SVG.
SVG layouts generally have fixed aspect ratio and layout; they scale, but
only in proportion. This makes things difficult for magnifiers, embossers,
large-print publishers and so on.  A figure role indicates a self-contained
section that can be safely re-positioned or printed on a separate page
without losing meaning.

Again, we don't know of any software ready and waiting to use this role in
this way.  However, providing the language to describe the semantics is the
first step in enabling such a tool.


On 8 September 2016 at 13:34, Richard Schwerdtfeger <>

> Alex,
> 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.
> 1. you should be copying the public-svg-a11y list which is public and it
> is where this work is occurring. It is on cc now.
> 2. We are creating a taxonomy for what is needed for graphics. A need by
> webcomponents is to create
> 3. Part of ARIA 1.1 is to create standard native host language semantics
> that are equivalent to HTML features. Steve specifically asked for the
> figure role. This also allows HTML AAM to reference a standard ARIA mapping
> 4. In SVG you don’t want a figure caption (in HTML) embedded in an SVG
> figure - it is likely to look dreadful. We can address this with an
> aria-labelledby to SVG text.
> Rich
> On Sep 8, 2016, at 1:59 PM, Alexander Surkov <>
> wrote:
> Hi.
> I'm trying to find a background information about figure role, where it
> comes from and what is its use case. I was able to find couple email
> threads on svg-a11y [1] and aria [2] mail lists, but they don't give much
> info. Rich said that the figure role comes from SVG needs:
> We need this for SVG Accessibility as we need a mechanism to isolate
> figures that could be pulled into a list of figures by assistive
> technologies.
> Since ARIA role='figure' replicates HTML figure element, which doesn't
> have UI and is basically a pure semantic element, then I'm curious whether
> this element can be reused in SVG world.
> What is criteria for introduction of a new role/feature in ARIA that
> copies semantics of a HTML element?
> Thanks.
> Alex.
> [1]
> [2]

Received on Tuesday, 13 September 2016 04:55:41 UTC