Add aria-labelledby attributes to comment form

[joedolson]

The aria-labelledby attribute provides a means for screen readers to get additional context for inputs when there is additional labeling information provided. In the default comment form, information such as the fact that email will not be published or that HTML tags and attributes can be used can only be viewed through a separate pass through the form not in forms mode. Adding these attributes means that a screen reader will read both blocks of text as the label for the field.

[obenland]

Do we really need additional html elements for the ids? Can't the labels or the p elements carry them with the same effect?

[joedolson]

Updated patch for aria-labelledby

[joedolson]

That occurred to me as well pretty well immediately after posting the patch. We can use the label to carry the ID for the comment form, eliminating that extra HTML element, but need to keep the span element for the email address notice. Adding the id to the paragraph element there would mean that the required text string would be included in the label as well, which would be redundant as it is already announced as required because of the aria-required attribute. New patch attached.

[bramd]

Shouldn't we use aria-describedby here to associate the email notice? THen it will usually be spoken after the contents of the field by screenreaders.

[joedolson]

The same is true of aria-labelled by; mostly it's a question of whether the additional text is an extended description of the field or an extension of the label. But either will work and be perfectly acceptable, functionally.

[GaryJ]

How come the comment label gets an id attribute that is then referenced in the aria-labelledby attribute for the comment field (good), but the email label gets an extra wrapping span with an id and that's referenced in the aria-labelledby attribute in the email field instead? Why the inconsistent approach (direct ID versus wrapping span with ID)? The required span is already completely inside the label, and the label is wholly inside the new extra span. The latest patch is:

<span id="email-label"><label ...>...</label></span>

Could it not be:

<label ... id="email-label">...</label>

?

[joedolson]

I have no memory of why I might have done that; it doesn't seem logical. It's probably just a mistake...

[joedolson]

Updated patch

[joedolson]

Patch refreshed. Cleaner HTML, doesn't have all the extra span elements. Does still add a span element surrounding "Your email address will not be published"; this is because wrapping the entire paragraph includes the required field notice, which is redundant combined with aria-required, which already announces the fact that the field is required.

[GaryJ]

How do user agents handle references to ID elements that don't exist (as in, what happens if comment_notes_before and comment_notes_after are filtered to be an empty string?

---

Have you listened to what the comment field is now announced as? Listen to ​http://clyp.it/oilalv1h (also attached as an MP3 for future reference). As a non-AT user by default, that doesn't sound as helpful as it could be.

Here's a transcription of the the start of what's read aloud by ChromeVox (spoken letters in capitals):

"comment you may use these HTML tags and attributes colon less than A HREF equal quote quote title equal quote quote greater than less than ABBR title equal quote quote greater than less than acronym title equal quote quote greater than less than B greater than less than..."

Would it be any clearer for non-visual users to have something like:

""comment you may use these HTML tags and attributes colon A with HREF and title attributes, ABBR with title attribute, acronym with title attribute, B, ..."

...read out instead?

If so, then assuming #29699 goes in, we could check for screen-reader-text support and have a friendly version for screen readers which is referenced from comment field aria-labelledby, and hide the original visual markup with aria-hidden.

Incidentally, ChromeVox consistently cut-off at the same place each time when reading out the visual markup, just after reading the "cite" tag. I don't know if this is a bug with ChromeVox, or my setup, or something about the length of the sentence or other issue that may affect other text-to-speech implementations.

[joedolson]

I wouldn't recommend using ChromeVox as a good basis for testing; it's not heavily used as an AT resource. For a free screen reader testing option, use NVDA. (See ​http://webaim.org/projects/screenreadersurvey5/)

I didn't test this using ChromeVox. A user agent should ignore the attribute value if the target doesn't exist, so that should be fairly harmless.

NVDA reads this fine, using default settings. Reading of punctuation is configurable, so if somebody has less than/gt signs configured to be read, that would be different, but they're read understandably normally.

[bramd]

Use aria-describedby for the help text on the comment field and remove aria-labeledby attribute since the relation is already made using <label for="...">

[bramd]

Last patch has been tested by me and others in NVDA + Firefox, JAWS + IE and VoiceOver on Mac + Safari. I think this is ready to be commited.

[SergeyBiryukov]

In 29846:

Add aria-describedby attributes to comment_form().

props joedolson, bramd.
fixes #24148.