Hi, Rich.
On Wed, Sep 14, 2016 at 4:56 PM, Richard Schwerdtfeger <sch...@us.ibm.com> wrote: > Alex, > > 1. Figure is not just semantic as you expect <figcaption> to go with it > and there is no desire for that in SVG > I wish to have more details on this, because as I see it <figcaption> is just a label for <figure> and the authors may or may not use it if they want. > > 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. > I didn't suggested to extend SVG, right? Among other things SVG2 says: "SVG 2 Requirement. Resolution: Allow audio, canvas, iframe and video elements from HTML5, don't introduce almost the same but slightly different SVG NS elements. Purpose: To allow various HTML embedded content elements to be used directly in SVG and support dynamic loading of content." [1]. It looks like HTML figure can be re-used in SVG, according to this requirement. > > 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. > I'm good to extend ARIA as long as it's needed, but still I need to understand a use case for each new feature. > > 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). > Are there any links on public discussions where I can learn more about the web platform initiatives and why they need semantics for all HTML elements in ARIA, or could you cc someone, who will kindly outline their ideas on this list, please? > > Steve Faulkner asked for a Figure role and we needed one for SVG (Amelia's > email). So, we created a role for it. > Steve, could you please put your thinking here about figure role? > > 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. > fair enough, but still I've got more involved at implementation stage, because I'd need to understand each feature I add into Gecko. [1] https://www.w3.org/TR/SVG2/embedded.html > > Rich > > > > Rich Schwerdtfeger > > > > ----- Original message ----- > From: Alexander Surkov <surkov.alexan...@gmail.com> > Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org > To: Rich Schwerdtfeger <richsch...@gmail.com> > Cc: IA2 List <accessibility-...@lists.linux-foundation.org>, Alexander > Surkov <asur...@mozilla.com> > 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.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 > > > >
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
