Getting back to the figure role...

In discussing this, I had actually forgotten that Firefox (and Chrome) already maps the HTML figure tag to role grouping with xml-roles:figure. My apologies. So, there's no controversy here about the role: role="figure" should be mapped the same way as HTML figure (role grouping and xml-roles:figure).

For reference, there was some controversy about this 5 years ago when this decision was made. Back then, Alex and I argued it should be a role, but others disagreed for backwards compat reasons. We ended up agreeing to use xml-roles. The discussion is on this Mozilla bug:


On 17/09/2016 11:25 AM, Rich Schwerdtfeger wrote:
Then give it a role but don't take a week of people's time arguing over it. We have harder problems to work on.


Sent from my iPhone

On Sep 16, 2016, at 8:00 PM, James Teh < <>> wrote:

IMO, xml-roles is a really horrible hack. An object attribute makes sense for things like landmarks because a landmark is more like an attribute of the element, rather than how it behaves/what it is. I argued a long time ago that landmark should have been a specific "landmark" attribute, but xml-roles is nevertheless what we have now. Relying on this hack even further seems really ugly to me. If figure is an important semantic construct, it really should have a role, just like heading, etc.

Sent from a mobile device

On 17 Sep. 2016, at 9:33 am, Rich Schwerdtfeger < <>> wrote:

I have not checked. We have been trying to work with you on this first and that has taken well over a week on just figure. We are now working with other browser and ATVs now. The current mapping also does not require an API change.


Sent from my iPhone

On Sep 16, 2016, at 8:47 AM, Alexander Surkov < <>> wrote:

On Thu, Sep 15, 2016 at 5:53 PM, Rich Schwerdtfeger < <>> wrote:

    Hi Alex,

    That is indeed what ARIA has as the HTML AAM points to that
    mapping in ARIA Core:

    and the HTML AAM points to it. So, for the figure role we are
    all set.

    Is that currently implemented in Firefox when you an element
    with role=“figure”? … ROLE_SYSTEM_GROUPING and xml-roles:figure
    object attrib

It's not yet implemented in Firefox. Btw, do you know if other browsers have supported it?

    If you do already, I will work with Windows ATVs to start
    supporting it on Windows.

HTML:figure is accessible in Firefox. ARIA role='figure' should have identical mapping. If screen readers support HTML:figure, then they don't have to make any extra effort to support ARIA role='figure'.

    Please map that for for SVG elements when it is applied as
    well. Then we can discuss their participating in a list of
    figures in ATVs as part of the AT UIs.


    Rich Schwerdtfeger

    On Sep 15, 2016, at 1:00 PM, Alexander Surkov
    < <>> wrote:

    Thank you, Marcos.

    I'm getting lost in the discussion as it goes in two separate
    threads/groups (IAccessible2 one and SVG groups).

    I buy Doug's argument [1] that non browser SVG tools may not
    HTML, but still they are keen to support ARIA to make their
    accessible. This argument can be a justification for ARIA
    figure role
    I think.

    Having said that, I'm adherent to the idea of re-using HTML
    in SVG documents. The author should be able to use standard
    HTML and
    SVG blocks to make the content accessible. <foreingObject>
    perhaps is
    not the most convenient structure to embed HTML into SVG, but it
    works, which makes ARIA role='figure' less valuable in the

    I don't think that ARIA role='figure', implemented in the
    may harm anyone, I'd be interesting though to hear from other
    on this topic.

    Rich, I think ARIA role='figure' should have same IAccessible2
    as HTML figure element has, which is ROLE_SYSTEM_GROUPING and
    xml-roles:figure object attribute.

    Thank you.


    On Thu, Sep 15, 2016 at 1:19 AM, Marcos Caceres
    < <>> wrote:
    On September 15, 2016 at 2:10:09 PM, Rich Schwerdtfeger
    ( <>) wrote:
    Alex, both Doug and Anna have expressed to you the opinion
    of the SVG working group to not
    have those elements in SVG. At this point the discussion on
    adding or using them is not

    With all due respect, if Mozilla is supposed to implement
    this, we
    need our queries addressed properly.

    Mozilla's position is that developers should be able to use
    HTML element/attributes in SVG, where they are
    semantically/structurally useful. It clearly doesn't make
    sense to
    redefine things that are in HTML in some new SVG version.

    I would kindly ask that Alex's requests for clarification are

    Kind regards,

    Accessibility-ia2 mailing list

Accessibility-ia2 mailing list <>

James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
Twitter: @NVAccess

Accessibility-ia2 mailing list

Reply via email to