Re: figure role backgrounds

Hi, Amelia. Thank for you for so detailed answer. Still I think I have some
unresolved concerns. Please find my answers inline.


On Tue, Sep 13, 2016 at 12:55 AM, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

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

I buy the argument that you may need HTML figure semantics in SVG, I'm not
yet sure that ARIA has to be extended to address it, because HTML already
has <figure> and it can be reused in SVG document. See Anne's answer on
this thread [1].


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

Back in the days ARIA was created to make inaccessible DHTML apps
accessible, so there's a reason for role='button', which makes custom
buttons accessible, or for role='grid' which is used to create grid-like
elements. In other words, ARIA served to make content accessible that
cannot be made accessible by means of native markup like HTML. If the
purpose of ARIA has been changed over years, then I think I missed it.


>
> ARIA is available to be used in any XML syntax, including SVG and ePub.
>

Still, you can mix XML syntaxes and keep so many of them in one document as
you want.


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

I'm not certain whether this is a correct use case for ARIA, because in the
first place ARIA is markup that browsers understand, and it may have
nothing in common with native applications (because if there's no XML-like
language for native apps UI, then there's no place to put ARIA at). If ARIA
is going to describe all variety of native apps for purely academical
proposes, then it should bloat ARIA as it has to describe all kinds of
content, as well different but semantically close content. Also it may be
not that clear what part of ARIA should be implemented by browsers, and
what part is for reference purposes.



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

Honestly I don't quite understand why ARIA would need equivalents for every
HTML element having semantic.

Thank you.
Alex.


[1] https://lists.w3.org/Archives/Public/public-aria/2016Sep/0048.html


>
> 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 <richschwer@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.alexander@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
>>
>>
>>
>