JAWS Changes Requested: "Trigger an alert" (Alert Example, Test 3, V23.12.06)

[RFischer-FS]

In our previous discussion in "Trigger an alert in reading mode" (Alert Example, Test 1) on Issue #840 at w3c/aria-at (Feedback: "Trigger an alert in reading mode" (Alert Example, Test 1) · Issue #840 · w3c/aria-at (github.com)), we reached a consensus that announcing the role should be optional. However, with the recent updates to the evaluation system, the role announcement has been reclassified as 'Should', and not including it results in a failed test. Since we had already agreed to categorize the announcement for ‘role’ as optional, it should be marked as ‘may’ in the guideline, and therefore, non-compliance with this should not be considered a test failure.
To reiterate our reasons for this stance:

1. Overuse of alerts on many websites leads to an overwhelming amount of alert announcements, burdening the user with repetitive notifications.
2. Users facing websites with excessive alerts lack a practical way to disable only these role announcements, which can significantly hinder their experience.
3. Alerts are often brief, as illustrated by your example using the word "Hello." Adding the word 'alert' unnecessarily extends the message without offering clear benefits.
4. The 'alert' role doesn’t provide essential information; it merely indicates when the text is announced, not how users should interact with the element.
   Consequently, we have decided not to announce the alert role and do not intend to revert this decision. I hope that this can be reflected in the guidelines with the use of ‘May’ for the previous ‘optional’ element.
   A recent browser update indeed caused JAWS to start announcing the 'Alert' role under certain conditions, as observed with the JAWS 2023 versions tested earlier. It would be beneficial if the test could also reflect changes in the browser used between different test sessions. We are actively working to resolve this issue, as it conflicts with our commitment to providing a screen reader that maximizes user productivity.

Thank you.

Test Setup

• Test File: test-03-triggerAlert-jaws.collected.html
• AT: JAWS

[mcking65]

@RFischer-FS

"Should" is one of two levels of optional. Nonetheless, I agree there is room to discuss whether or not "may" is the appropriate level of optionality.

Your feedback reminded me of an item that fell too far down my to-do list, which was to lead the community group through the process of formally defining the priorities. I have raised issue Define meaning of assertion priorities: "MUST", "SHOULD", and "MAY" · Issue #1033 · w3c/aria-at. The community group should formalize those definitions before we discuss whether conveying the alert role should be prioritized as "SHOULD" or "MAY".

[mcking65]

@RFischer-FS,

The community group is discussing the definitions of SHOULD and MAY within the context of ARIA-AT tests. The SHOULD and MAY priorities both represent levels of optionality. Our current draft definitions are:

SHOULD: The assertion is a strongly recommended requirement. The command or event being tested SHOULD result in the behavior described by the assertion. Failure to do so is likely to impede users of the command from perceiving, understanding, or operating the type of content represented by the test case. There may exist valid reasons in particular circumstances to ignore this assertion, but the full implications must be understood and carefully weighed before choosing a different course.

MAY: The assertion is truly optional. The command or event being tested MAY result in the behavior described by the assertion. Failure to do so is not likely to impede users of the command from perceiving, understanding, or operating the type of content represented by the test case. One assistive technology (AT) vendor may choose to provide the asserted behavior because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same behavior.

When we meet today, we'd like to discuss these draft definitions, how they apply to this issue, and the various perspectives raised by CG members. This issue is a good test of our proposed definitions for the priorities.

[lolaodelola]

Notes following today's meeting, we discussed some nuances around assertion priorities and how we can apply them.

• It was discussed that the pass/fail language may not always be appropriate, especially for optional assertions as not implementing something optional isn't a failure. There was some discussion of using supported/unsupported or yes/no in these cases.
• Using alert as an example, the intention of alert as according to specification and guidelines differs from how it's implemented in practice by web developers, with many web developers misusing alert.
  • it was discussed that the important thing that should be announced is the content of the alert so a test asserting the content of the alert is announced would be a MUST. However, the role of alert doesn't need to be announced as there can be other ways to convey alert (e.g. change in AT voice) so speaking the role should be MAY.
  • The current automated system can only interpret spoken language (not braille, not changes in voice) which means language conveyed in other ways can only be tested by manual testers at this current time.