Alex,
1. Figure is not just semantic as you expect <figcaption> to go with it and there is no desire for that in SVG
2. If you look at the SVG2 spec. they list all the elements they want in it (including <iframe>. They have chosen to NOT have it in the specification and it is in lock down.
3. If you recall from the first ARIA 1.1 meeting we had in Toronto (at Mozilla) the intent was to reproduce HTML semantics in ARIA as they are needed. This is in large part to ensure that HTML elements can be defined in terms of ARIA semantics so that they can be mapped to those semantics.
4. Given that HTML has a LOT of elements, we are picking those that can be easily mapped and for which there is an inherent need first. The Web Platform people want semantics for all HTML elements in ARIA as they want to get away from using HTML and create their own DOM. So I expect roles for virtually all HTML elements (including block quotes).
Steve Faulkner asked for a Figure role and we needed one for SVG (Amelia's email). So, we created a role for it.
There are a lot of features in ARIA 1.1 that people need to have us get out into browsers and we had a limited timeline for ARIA 1.1. It is for these reasons that we cut the features off putting all HTML roles into ARIA 1.1.
If you would like to participate in setting the bar lower or higher you should participate more when we start ARIA 2.0. I believe you were at that first meeting at Mozilla when we kicked off ARIA 1.1 work.
Rich
Rich Schwerdtfeger
----- Original message -----
From: Alexander Surkov <[email protected]>
Sent by: [email protected]
To: Rich Schwerdtfeger <[email protected]>
Cc: IA2 List <[email protected]>, Alexander Surkov <[email protected]>
Subject: Re: [Accessibility-ia2] Fwd: figure role backgrounds
Date: Wed, Sep 14, 2016 3:17 PM
Hi, Rich. There are still concerns left. Here's my email [1].Alex.[1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0051.htmlOn Wed, Sep 14, 2016 at 10:22 AM, Rich Schwerdtfeger <[email protected]> wrote:Alex,Are you satisfied with Amelia’s more detailed response and why it is needed in SVG? Figures are used a lot in SVG drawings.If so, I would like your approval on the figure mapping. I am trying hard to get ARIA 1.1 wrapped up so that we can focus efforts on helping you and others on the _javascript_ Accessibility API work and other work around ARIA 2.0. I just had a meeting with a product team and they are screaming with a lot of the changes that are going into ARIA 1.1: feeds, aria-haspopup value changes that include dialog and tree and much more.RichRich Schwerdtfeger
Begin forwarded message:From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com >Subject: Re: figure role backgroundsDate: September 12, 2016 at 11:55:09 PM CDTTo: Alexander Surkov <[email protected]>Cc: ARIA Working Group <[email protected]>, SVG-A11y TF <[email protected]>, Richard Schwerdtfeger <[email protected]>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 application.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 important: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 separately)
- 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 document)
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.~ABROn 8 September 2016 at 13:34, Richard Schwerdtfeger <[email protected]> wrote: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 create3. 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 mapping4. 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.RichOn Sep 8, 2016, at 1:59 PM, Alexander Surkov <[email protected]> wrote:Alex.Hi.Thanks.
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 isolateSince 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.
figures that could be pulled into a list of figures by assistive
technologies.
What is criteria for introduction of a new role/feature in ARIA that copies semantics of a HTML element?
_______________________________________________
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
