Asterisks for certain fields are not announced by JAWS. As an example within the “Create Image” screen, the “Image Upload *” button is announced by JAWS as, “Image upload file upload edit browse…” instead of being correctly announced as e.g. “Image upload required file upload edit browse…”
The defect exists in IE 11 and Google Chrome v55.0.2883.87 m.
Expected result: All asterisks are expected to be announced by JAWS. For example required red asterisk is expected to be made available for JAWS to read with the associated form title e.g., “Image upload required file upload edit browse…”
Reference: Section 508, Part 1194.22, Paragraph (n).
Notes:
• This defect may exist elsewhere within the application.
• This defect exists on a screen that is not accessible via a keyboard. The tester was forced to use the mouse to access this screen, which is not acceptable for a JAWS user.
Comments
Comment #2
kershme CreditAttribution: kershme commentedComment #4
findleys CreditAttribution: findleys commentedThis issue appears to be specific to required file uploads. The required class is on the label, but not the input fields. The reader is reading the choose file button prior to file upload and the file name after file upload.
Comment #5
mgiffordThanks for the update.
Comment #6
apadernoComment #7
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedbugs are still eligible for 8.4.x patch releases.
Comment #8
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedThanks @findleys ans @kershme, I've replicated this.
There's no programatically determined indication that a file field is required. The only indication is the red asterisk, from the
label.form-required
class.This relates to WCAG 1.3.1 Info and Relationships, and 3.3.2 Labels or Instructions, . Interestingly, WCAG 2.0 doesn't mention the HTML
required
attribute, presumably because it was introduced by HTML5 and wasn't around when WCAG 2.0 was published. So there isn't a "common failures" document in WCAG for this problem. The most relevant document is probably ARIA2: Identifying a required field with the aria-required property which describes using the related aria-required property.Comment #9
apaderno@#8 Yes, but first they are fixed on Drupal 8.5, and then back-ported to Drupal 8.4.
Comment #10
apadernoComment #16
bskibinskiThis issue still exists in 9.3 for file/image upload fields.
First off, I think drupal should improve the way it displays the asterisk:
Improve 'required asterisks' in general
At the moment, drupal's default way of showing the asterisk is through CSS (through a pseudo :after element).
This in my opinion is already not great, because screenreaders can't 'see' it.
Solutions
Solution 1 - add text
A good 'simple' improvement would be to just add the text "required" and make that text 'visually-hidden', this way you can leave the old css asterisk as is.
Solution 2 - add svg
replace it with an SVG asterisk, with a aria-label="required" and title="required" (for a nice mouse over popup).
remarks
This would at least make the required part readable for screenreaders, so even if an input field lacks the proper 'required' attributes, at least the label will tell them it's a required field, which is already an improvement.
caveats
This could be a bit more difficult for conditionally set required fields (like through webforms).
Now, you can easily show/hide the asterisk by adding/removing one class through javascript.
My proposed solutions will only work for conditional fields, when you always render the required-icon/text in the twig file, and display:none them by default, to only show them when a field gets the required class.
Or, to set the text/icon through Javascript, but this seems more dirty to me.
but perhaps there are better solutions i didn't think off.
Add proper required attributes to file upload fields
The real issue is not fixed with my previous suggestion.
So adding the "required" & "aria-required="true"" would still need to be done for file uploads.
But as I understand, there is no good way to determine this programmatically (if i read the comments correctly), so that ability should be added to drupal core.