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.

[Garneauma]

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

[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)

• 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 #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]

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?