Hi, Rich. There are still concerns left. Here's my email [1].

[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>

> 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

Reply via email to