Page feedback tool: Polish AJAX fragments (FR pageData, role="status")

[EricDunsworth]

The AJAX fragments had two minor flaws:

• The English fragment contained pageData references that were missing from the French variant. That difference caused a hidden input named "contact" (with a JSON string as its value) to be injected into French feedback widgets. Although it didn't cause any other issues (data-feedback-link and data-feedback-url still worked fine in practice).
• The no button's invisible transition message in JS mode is technically a status message, but wasn't coded as such (was using aria-live="polite" as opposed to role="status").

This resolves the flaws by:

• Adding pageData references throughout the French fragment (same spots as English) to eliminate the hidden "contact" input.
• Replacing aria-live="polite" with role="status" in the no button's transition message:
  • role="status" is a more formal way of denoting status messages, implicitly sets aria-live="polite" + aria-atomic="true" and is already in use for the widget's thank you message.

[EricDunsworth]

Need a reality check on whether it was appropriate to update these lines.

The feedback component's version seems to be tracked separately from the PFT "sub-component"...

Since I updated the PFT to version 1.1 (shown as 2 in JSON-LD iteration variables)... I figured it'd also make sense to update feedback to 2.1 (since PFT "belongs" to it).

[EricDunsworth]

Are these "AJAX fragment:" prefixes appropriate?

Are there any standardized prefixes these kinds of notes are supposed to follow?

Here's what I've spotted:

• Some pre-existing fixes arrays contain no prefixes at all, whereas others use "Demoted/Style:".
• The similar-looking breaking/additions arrays are usually prefixed with "Layout/Semantic/Behaviour:"... but sometimes lack prefixes.

[Garneauma]

Pre-approved upon successful code review and accessibility testing. This will need to be coordinated with an AEM release.

[Garneauma]

@EricDunsworth I have not noticed any difference between having the aria-live="polite" and role="status" either with NVDA or MAC OS accessibility tool. Also, the only gain I can see from having role="status" is to have the implicit attribute aria-atomic="true" which would read the whole content of the container that has the attribute role="status". In this case, since the element in question is <p class="nojs-hide wb-inv" role="status">Tell us why below:</p>, the whole element is updated (shown) and not a child element, so the aria-atomic="true" has no impact.

If you are adamant about having this change included in the file, please provide an accessibility conformance report that clearly highlights what accessibility standards the current solution fails. We will then assess the situation and make the necessary changes.

I would be happy to discuss this further if you have questions or concerns.

I will, however, gladly accept the changes to the French version of the asset so that it matches the English one. This would be a patch. The changes to the index.json-ld would need to be reverted.

[EricDunsworth]

@Garneauma Here's my in-depth rationale for the aria-live="polite" to role="status" change:

• Semantically, role="status" is a better fit for the no button's transition message ("Tell us why below:") than aria-live="polite":
  • role="status" represents a role, whereas aria-live="polite" is a property of that role
  • Content fits the ARIA 1.2 spec's definition of the status role:

    status role
    A type of live region whose content is advisory information for the user but is not important enough to justify an alert, often but not necessarily presented as a status bar.

  • Content fits WCAG 2.x's definition of a status message:

    status message
    change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

  • Every situation for all of WCAG 2.x SC 4.1.3's sufficient techniques expect at least one technique involving the role attribute to be used
  • WCAG 2.x's status messages technique (ARIA22) expects role="status" to be used for that purpose (albeit in combination with other techniques that don't apply to the content in question)
• The thank you message ("Thank you for your feedback.") is also a status message and currently uses role="status"
• Status messages aren't currently denoted consistently between the no transition message (aria-live="polite") and the thank you message (role="status")... IMO it'd make sense to code them in a consistent manner

[EricDunsworth]

Two more points:

• If an AT were to try identifying a status message based on its semantics, I'd expect it to be detected via role (as opposed to aria-live)
• Page feedback tool: Revamp #1916 initially proposed using aria-live="polite" for both status messages. So both messages were originally coded consistently.
  • IIRC VoiceOver had issues with the initial markup and it was ultimately revised in Feedback: implementing Page Feedback Tool #2098. But the semantics for both status messages diverged somewhere along the way...
    • aria-live="polite" was kept for the no message
    • The thank you message was changed to role="status"

[duboisp]

This PR is rejected, the use case is not valid according to the WCAG definition of status message 4.1.3

Where the SC of 4.1.3 is defined as:

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

I will take a peek later at the understanding but so far the current markup is passing the SC 4.1.3 even if it don't use the explicit role "status".

[duboisp]

This is not a status message according to WCAG definition. That don't represent the result of an user action.

The line 80 is the status message and it is marked by using the role=status

[EricDunsworth]

I previously explained my rationale in-depth in #2401 (comment) and #2401 (comment).

But I'll explain exactly why I think the no message fits within ARIA and WCAG's definitions below... :).

---

Here's ARIA 1.2 spec's definition of the status role:

status role
A type of live region whose content is advisory information for the user but is not important enough to justify an alert, often but not necessarily presented as a status bar.

IMO "Tell us why below:" is advisory information that isn't important-enough to warrant an alert nor a status bar. It's triggered as the direct result of a user action (i.e. pressing the "No" button).

---

Here's WCAG 2.x's definition of a status message:

status message
change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

IMO "Tell us why below:" represents both information on the result of the act of pressing the "No" button, as well as the progress of the process of providing feedback. It's the second "step" in the process of providing negative feedback.

[duboisp]

To remove the confusion, we would need to do and document actual test with AT that illustrate the issue and that are illustrating the solution are fixing the issue. Those test can be documented into a partial accessibility assessment.

[EricDunsworth]

To remove the confusion, we would need to do and document actual test with AT that illustrate the issue and that are illustrating the solution are fixing the issue. Those test can be documented into a partial accessibility assessment.

@duboisp
Just to clarify, my goal with adding role="status" wasn't to fix a specific screen reader issue.

My initial intent with this PR was to fix the French pageData references, but while prepping it I randomly noticed that ARIA semantics were being used inconsistently on what I'd consider to be two status messages. So I decided to make them consistent by using role="status" on both (which appears to be the most semantically-correct way of denoting status messages).

I only have NVDA at my disposal, but from what I tested while prepping the PR, both aria-live="polite" and role="status" functioned identically in practice (which makes sense given that role="status" implicitly sets aria-live="polite" and aria-atomic="true").

I don't think there'd be much value in attempting to document this change's impact on screen readers. Both the "before" and "after" behaviour is identical. Not to mention that role="status" is already being used in one of the status messages without any issues. This situation doesn't involve quirky AT behaviour, so there isn't really anything worth documenting.

In any case, if you feel strongly about this and would prefer to keep the status quo, I could revert the role="status" change and focus solely on the French pageData fixes.

Thoughts?