Re: SVG Accessibility API Mapping Spec: Significant edits

Regarding animations:

I was not suggesting that any changes to states happen automatically,
except for the determination of whether or not something is hidden.  For
all other aria attributes, the author would control the animation start and
end, the same as for any other SVG attribute.  I'm just saying that the
author should be able to control them using the same declarative SMIL
markup with which they control the animated effect.

E.g., you could create a play/pause button that controls another
animation.  When the animation is running, you would want to change the
description of the animated content, and the state of the button.  The
entire animation is defined using declarative markup, but there is
currently no equivalent way to update ARIA states and properties.

The problem is that SMIL animations do not change the actual attribute in
the DOM that browsers use to build the accessibility tree.  If we want
animations to have an effect, we need to define these attributes as
animatable, and tell browsers to update the accessibility API mappings
accordingly.

It's a slightly academic debate, since Chromium has no plans to update
their SMIL implementation and Microsoft has no plans to implement one.
However, defining the attributes as animatable could have impacts on the
web animations specification.

_____________

Regarding whether something is hidden or not:

In hindsight, we might not need a separate section for how animations
affect visibility.  The new CSS cascade spec clearly indicates that
animations affect the computed style, so it would just be treated the same
as any other style change.

It does emphasize the issues I have with the general approach that
invisible == nonexistent.  An element that is invisible because of opacity
or visibility properties is still part of the rendering tree.  And there
are actually quite a wide number of possible combinations of properties and
styles that can cause an element to become invisible.  I don't think we
want to iterate them all!

I know CSS/HTML has the same issue, where sometimes authors want something
to be visually hidden but still recognized by screen readers or able to
receive focus.  There are all sorts of workarounds to make something
invisible but not hidden from ARIA.

The problem is that the CSS/HTML approach has led to implementations
treating visibility: hidden as equivalent to aria-hidden=true, and that is
not appropriate for SVG because of the way the pointer-events options work.


On 25 June 2015 at 08:10, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

> Thanks Amelia. We are really glad to have you on the team.
>
> aria-pressed is a state so it can change. However, if we want to have the
> user agent do something automatically we would need to clearly specify how
> that is done. ... What triggers aria-pressed to go away? What role is
> applied that would allow aria-pressed to be used? Is aria-pressed the right
> state to describe what is going on?
>
> Is it a binding to animation that stops (does not look like it). ... Or is
> it the act of the UI element becoming invisible. We are going to need to
> establish rules for what is considered hidden automatically. Is opacity of
> "0" an example and should it disappear from the accessibility tree? If it
> disappears from the accessibility tree we won't care if it is pressed or
> not as there will be no object to bind it to. Also, in these instances we
> need to make sure that we do something that will work in all cases without
> exception.
>
> Rich
>
>
> Rich Schwerdtfeger
>
> [image: Inactive hide details for Amelia Bellamy-Royds ---06/25/2015
> 08:52:57 AM---What I have is still isolated to my fork of the repo]Amelia
> Bellamy-Royds ---06/25/2015 08:52:57 AM---What I have is still isolated to
> my fork of the repo (I don't have push access to the ARIA repo).  Y
>
> From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: public-svg-a11y@w3.org
> Date: 06/25/2015 08:52 AM
> Subject: Re: SVG Accessibility API Mapping Spec: Significant edits
> ------------------------------
>
>
>
> What I have is still isolated to my fork of the repo (I don't have push
> access to the ARIA repo).  You'll probably want to pull it in as a separate
> branch, then you can edit away.
>
> Regarding `aria-pressed`, the issue wasn't if the property was available,
> it was whether you could change it with SMIL animation.  See this tutorial
> of how to make an animated toggle button with SMIL.  Currently, to make it
> ARIA-accessible, you'd need to use scripting to change the ARIA attributes:
> *http://codepen.io/mikemjharris/blog/svg-toggling*
> <http://codepen.io/mikemjharris/blog/svg-toggling>
>
> ABR
>
> On 25 June 2015 at 07:33, Richard Schwerdtfeger <*schwer@us.ibm.com*
> <schwer@us.ibm.com>> wrote:
>
>    Thank you Amelia.
>
>    Addressing each bullet:
>
>    - We do need to keep them synchronized but I can look at how we might
>    reduce it. It is important that a user agent manufacturer be able to read
>    this spec. and get the gist.
>    - The issue with <desc> is it is not visible. Also, some platforms
>    don't yet support access to structured text e.g. Mac, iOS. Even if it is
>    structured, if structure is important then it should be visible to all
>    users. For that we have aria-describedby but even that is limited by
>    platforms that don't support description relationships.
>    - I need to look at dat viz. This may be sticky issue with user
>    agents.
>    - tabindex on non rendered are ignored. They must not be exposed to
>    AAPI
>    - Role mappings that use of a generic ARIA role: One does not exist
>    but we can create one. Most platforms expose the passed ARIA role. We could
>    default to "graphicalobject" but I thought we agreed these would be
>    symbols. I agree we should default to the new graphics roles.
>    - aria-busy is a global attribute so we can put it anywhere we need
>    to. We may wish to put something about aria-busy usage in this spec. or the
>    ARIA specification. I am not following how aria-pressed applies.
>    aria-pressed applies to toggle buttons typically as it reflects the pressed
>    state.
>
>    Do you want me to edit what you have or create a branch off your
>    branch? I will take a look at what you have.
>
>
>
>    Rich Schwerdtfeger
>
>
>