Hi, Rich. There are still concerns left. Here's my email [1]. Alex. [1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0051.html
On Wed, Sep 14, 2016 at 10:22 AM, Rich Schwerdtfeger <richsch...@gmail.com> 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. > > Rich > > Rich Schwerdtfeger > > > > > Begin forwarded message: > > *From: *Amelia Bellamy-Royds <amelia.bellamy.ro...@gmail.com> > *Subject: **Re: figure role backgrounds* > *Date: *September 12, 2016 at 11:55:09 PM CDT > *To: *Alexander Surkov <surkov.alexan...@gmail.com> > *Cc: *ARIA Working Group <public-a...@w3.org>, SVG-A11y TF < > public-svg-a...@w3.org>, Richard Schwerdtfeger <richsch...@gmail.com> > > 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 > <http://w3c.github.io/aria/html-aam/html-aam.html#html-element-role-mappings>.) > 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. > > ~ABR > > > On 8 September 2016 at 13:34, Richard Schwerdtfeger <richsch...@gmail.com> > 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 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 <surkov.alexan...@gmail.com> >> 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] https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug >> /0028.html >> [2] https://lists.w3.org/Archives/Public/public-pfwg/2015Oct/0023.html >> >> >> > > > _______________________________________________ > Accessibility-ia2 mailing list > Accessibility-ia2@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 > >
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
