1079145 - ARIA alert role fires system alert event when its dynamically modified, even with `aria-expanded="false"`

Status: RESOLVED WONTFIX

(Firefox :: Disability Access, defect)

Description

[Meri]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

When a page with a form throws a validation error (i.e "Mandatory field") we dynamically create a new DOM element with the error message and with a `aria-expanded="true"` attribute, followed by a slide in animation in jQuery.

When the user completes the mandatory field, we automatically hide the `role="alert"` element with the reverse jQuery animation, and before that, setting `aria-expanded="false"` to prevent JAWS from reading the alert again.


Actual results:

The JAWS tool reads the error before the folding animation on the "alert" happens.


Expected results:

JAWS should have ignored the element with `aria-expanded="false"`, as it happens in other major browsers we tested.

Comment 1

[Loic]

Do you have a testcase (webpage) to provide, please.

Comment 2

[Meri]

Sure thing Loic, here you have: https://preview.userzoom.com/s/userzoom.aspx?uc=C4S1639_28&

It's a questionare with several steps, you can have a try in any of them, because all questions are mandatory to answer.

Comment 3

[Marco Zehe (:MarcoZ)]

I can confirm that the alert also gets spoken when it is modified to be animated out of view.

my question is:
Where in the ARIA specification or the author's guide did you read that aria-expanded="false" would not cause a screen reader to read the alert? The way I see it, this is treated like a new alert and thus causes an event to fire. The expanded state is an inherited state, but I didn't see anything specifically mentioning that applying this would cause an ARIA alert not to be read.

Comment 4

[alexander :surkov (:asurkov)]

I don't recall anything similar as well. Cc'ing Joseph.

Comment 5

[Joseph Scheuhammer (:clown)]

(In reply to Marco Zehe (:MarcoZ) from comment #3)

> ...
> Where in the ARIA specification or the author's guide did you read that
> aria-expanded="false" would not cause a screen reader to read the alert?

You won't find anything that specific in the ARIA specs, namely how screen readers use the information in the accessibility API.  There are directives for authors and for browsers; specifically how browsers expose ARIA to accessibility APIs.  While it is a discussion point, for now ARIA does not dictate how screen readers or other ATs work.

That said, there is a section on accessibility events in the core mapping guide, with an entry for aria-expanded [1].  Changing the value of aria-expanded causes an event in the underlying accessibility API.  The specifics depend on which API.  I suspect that the FireFox+JAWS combination uses MSAA+IA2, which means an EVENT_OBJECT_STATECHANGE occurs.

I don't know if MSAA+IA2 provides the information that the state change was a collapse vs. an expansion.  Or, if JAWS cares about that distinction.

[1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#event-aria-expanded

Comment 6

[Joseph Scheuhammer (:clown)]

(In reply to Joseph Scheuhammer (:clown) from comment #5)
A followup.  The title of this bugs begins " ARIA alert role fires system alert event ...".  Regarding system alerts events, the mapping specification is neutral.  Quoting:

"This specification does not currently contain guidance for when user agents should fire system alert events. Some guidance may be added to the specification at a later date but it will be a recommendation (SHOULD), not a requirement (MUST)."  [1]

I believe David was present at the meetings where this was discussed (it's before my time); CC'ing David.

http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ftn.note2

Comment 7

[alexander :surkov (:asurkov)]

It's not clear with me what use case we want to address by providing the support of <div role="alert" aria-extended="false"></div>. Isn't it covered by <div role="alert" hidden></div>?

Comment 8

[Meri]

Alexander, the point here is, we want to override with ARIA attributes an attribute like the "hidden" you suggest. In this specific case, the semantic "hidden" (aria-expanded="false") should occur at the beginning of the animation, and the "hidden" attribute is set at the end of it. 

JQuery handles the DOM element multiple times during that animation, firing lots of "changed" events (or whatsoever) to JAWS, so the point is to semantically hide that element at the very beginning.

Please, ask for more clarifications if you need them. It's a bit tough to explain… :)

Comment 9

[alexander :surkov (:asurkov)]

So if you want to say the element is semantically hidden and you cannot use HMTL5 hidden attribute for this (I think I'm still not clear on a reason of it but I sort of believe in such scenario, for example, HTML5 hidden may make some visual computations hard if even not possible). So your case is you want to prevent AT communications until the element is ready. I'm curious if aria-busy can work here.

Anyway I think this talk should be part of some public ARIA discussion (like [e-mail]). You have use case and you need some ARIA solution for it.

Comment 10

[James Teh [:Jamie]]

Test case is gone, there's no solid spec justification for aria-expanded suppressing the alert event, and I actually think this might be fixed by bug 686400 anyway (since the animation probably wouldn't cause accessible re-creation). Closing.