Required fields are not identifiable on Internet Explorer 11 high contrast

Maybe we can replace svg icon by "*" symbol as a content: "*";'?

Patch details:

Made alterations to the background sizes.

Didn't replace it with content as the content will be read by screen readers. Please review.

Thanks!

Thanks, @sd9121 for the patch, it applies successfully.

Required fields(asterisk mark) are now visible on IE11 high contrast.

Screenshot:

Thanks!

Applied patch #4. Verified and tested the issue on IE11.
The required marker is visible. Looks good to me.

Tested the issue on the Internet Explorer 11 high contrast. Required Marker is visible for me.

Tested in the following 2 ways:
1. Installed and Enable 'High Contrast' extension
- Open up the site in the IE11 on the Browserstack
- Verified the required marker

2. Go to the System Preferences > Accessibility > Display > Choose options like 'Invert Colors'
- Open up the site in the IE11 on the Browserstack
- Verified the required marker

Marker is visible in high contrast but displaying little half cut.
Refer attached screenshots

@DeepaliJ the detail and screenshots in your review are great. It looks like the testing was not actually done with Windows high contrast mode, but different settings that impact contrast. More info on using Windows high contrast mode can be found here https://support.microsoft.com/en-us/help/13862/windows-10-use-high-contr...

#12-#13: @bmnjmn is correct. The screenshots in don't show Windows High-Contrast mode. This screenshot comes from the Chrome HIgh-Contrast extension (which I think has been ported to Chromium/Edge?).

Tip for screenshot evidence: get a full-screen capture. That way, we can confirm (a) Windows high-contrast mode is active (because the whole desktop environment will be changed), and (b) which application is active (we see the rest of the browser window, not just the web content). In addition to the browser window, you could also include the settings window to show which Windows high-contrast theme is active.

I've noticed that people testing with Windows high-contrast always seem to go for the yellow-on-black default theme. However users can specify ANY colour overrides they wish. Workplace disability assessors have told me that a popular choice among dyslexic users is a custom Win-HC palette such as sepia-on-peach. A red asterisk can't be guaranteed to have sufficient contrast, because we have no idea what the background colour will actually be. It would be better if the asterisk matched the colour of the label text in high-contrast mode.

I tested patch #4, and it doesn't fix the problem. I see the same as @lauriii in #7. The problem is that the asterisk is included using background-image. These are always stripped out by IE11 (originally by design, though that has been intentionally changed in Edge in favour of a text backplate). The patch in #4 doesn't address this, it just changes some sizes.

Important images are best as content, not a background image. It can be a HTML img, or CSS content.

Didn't replace it with content as the content will be read by screen readers.

It's true that CSS screen readers will announce text inserted like content: 'FOO', but they won't announce anything for content: url(foo.png) or an un-labelled SVG.

It doesn't matter how the required fields are indicated...

• It doesn't have to be an image. We could say content: "*". Screen readers already announce that is is required because of the attributes. However it wouldn't be a total disaster if screen readers announced "name asterisk, required". Inelegant, but the asterisk will be commonly understood by users in many regions.
• It's would be OK to show the actual word "required" there. There's an interesting related issue which help here - #2921627: Do not use a CSS-only required marker in forms per WCAG 2.0.

Triage:
@rainbreaw and I discussed this one today, about where it should be in the Claro roadmap.

We can live without some icons, but we can't live without an indication of required fields.

A relevant WCAG success criterion here is SC 3.3.2 Labels or Instructions at level A:

• If you don't know whether a form field is required, then you don't have complete instructions.
• If sighted users in the full-colour space see a required-asterisk, but the asterisk is missing in Windows high-contrast mode, then that's putting some users at a significant disadvantage.
• Effectively, high-contrast users may have to submit many forms twice, because they won't know which fields are required until after the errors come back. This is significant additional labour.
• This is an instance of WCAG failure F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information, also at level A.

Since this involves WCAG success criteria at level-A, it warrants major/must-have for the stabilization roadmap.

At the moment, I don't believe there is a way to reliably target high-contrast mode in CSS. There's currently no way to do this in Firefox, this post provides details about the addition of the prefers-contrast to the Firefox nightly build, but it's not clear when this will be added to a release. In addition -ms-high-contrast is no longer supported by Edge as of version 18, in favor of forced-colors

Since it doesn't seem possible to reliably identify high contrast modes, it sounds the implementation needs to be one that works in all modes. I don't think there's a way to do this without deviating a bit from the current design. Here are the two solutions that come to mind:

• Use content: "*" instead of a background image @andrewmacpherson mentioned in #14 this is acceptable, provided that the asterisk should match the label color. We'd need the designers to approve of making the asterisk match the label color. This article from Neilsen suggests same color asterisks are fine, which makes me comfortable with its usability. I played around with this and when the asterisk is the same color, it seems to work better positioned before the label - but that's just one subjective take.
• Add (required) instead of an asterisk, the approach being worked on in #2921627: Do not use a CSS-only required marker in forms per WCAG 2.0. This would be a bigger deviation from the design.

Both of the proposed solutions will technically suffice, but I would suggest that a better approach would be to simply use the word "required." Yes, this is a design shift, but it is far more clear to everyone seeing it. The word itself can be styled a little differently so that it doesn't feel like clutter.

The Nielsen Norman Group has a good article about marking required fields from a UX standpoint, and offers both the text and asterisks style options: https://www.nngroup.com/articles/required-fields/

From an accessibility standpoint, however, thinking beyond screen readers and including cognitive accessibility, using the word itself is far more concrete and easy to understand.

A good article that dives into this more: https://usability.com.au/2013/05/accessible-forms-2-required-fields-and-...

My preferred technique is to include the word ‘required’ in the label element to indicate mandatory form fields since the required fields will be clearly identified to all. Also the technique is robust in that it is well supported by browsers and assistive technologies.

For the record, there is also conversation in A11y and UX communities about whether or not it makes more sense to mark the optional fields with the word optional instead of the required fields. This would be a bigger shift and I'm not recommending it for Claro at this time, especially since there is still considerable debate about the quality of this approach. I'm simply documenting it so that it is in mind to consider further in the future.

Adding here based on our discussion:

Given that the goal right now is to get to stable and my comment is a big design change, I'd suggest using Ben's suggestion: "Use content: "*" instead of a background image" for the time being.

Note that the goal isn't necessarily to have the same *color*, but rather the same *contrast*

#15

The Mozilla Hacks article you linked to is a bit premature. There's still active discussion in the CSS-WG about what the values for prefers-contrast will be. The forced keyword has detractors; one of the issues is whether prefers-contrast is being conflated with forced-colors.

Since it doesn't seem possible to reliably identify high contrast modes,

You don't need to. Something like this usually works:

.form-item-required label:after {
  content: '*';
  colour: red;
}

In Windows high-contrast mode, the color: red won't be applied. No media query is needed.

We'd need the designers to approve of making the asterisk match the label color.

Not really. Designers don't get a say about colours in Windows high-contrast mode; that's the whole point of the feature. The user has explicitly overridden the author's choice.

If the author tries to dictate what colour the asterisk should be, then there's no guarantee that the asterisk will be clearly visible at all. For instance, if a Windows high-contrast user chooses a black text on a salmon-pink background, a red asterisk may be hard to see.

@andrewmacpherson and @rainbreaw addressed all the concerns/confusion I'd expressed earlier. This patch adds the asterisk in content: and removes the background image. Screenshots attached for IE11 and Firefox in Windows high contrast mode. There's also with default contrast so reviewers can see the slight visual change that comes from using content: "*" 'instead of a background image.

No interdiff since this does not build on prior patches.

Tested with both IE 11 and Edge 44, Windows 10, high contrast mode without any customizations. The required field asterisks is now visible.

Marking as RTBC.

Worked on #21.
Please review the patch

Worked on #23
23.3:
--font-size-s: 0.889rem; /* ~14px */
For 14px this is defined in variables.pcss.css can we use this to match 14px. or use
0.875rem.

Please consider this interdiff.

Worked on #27.
Attached screenshot for the reference.

I've tested this on Windows 10 in the 4 High Contrast Mode themes with IE 11 and it looks good to me. The margin reduction looks much better.