Broken off from #3137365: Date form element is unthemed since last commits .

We need to refactor the form styles to ensure

  1. Accessible. This means that borders, and focus states need to be visible in Windows high contrast mode. Forms need to be tested in high contrast mode in the following browsers
    • IE11
    • Earlier (non-chromium) versions of Microsoft Edge
    • Firefox
  2. We need to ensure that regular form type selectors are styled. This is for the use case where someone inserts a third party form script into their site.

Note that the high contrast styling is a bit weird. All borders (including transparent borders) are visible. This means that changing a border-color from transparent to opaque for a focus state will not be noticeable in high contrast mode. Also note that IE11 high contrast mode (not sure about Edge) does not show background images (including linear gradients).

For testing, you can download IE virtual machines at https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

CommentFileSizeAuthor
#27 select-spacing.png55.99 KBmherchel
#25 3142850-18-interdiff.patch1.56 KBmherchel
#25 3142850-18-full.patch90.27 KBmherchel
#21 3138440-21-interdiff.patch29.97 KBmherchel
#21 3138440-21-full.patch91.72 KBmherchel
#20 isiINbHR5oU.jpg14.78 KBkostyashupenko
#20 Снимок экрана 2020-06-01 в 22.55.10.png102.83 KBkostyashupenko
#20 Снимок экрана 2020-06-01 в 22.44.46.png38.18 KBkostyashupenko
#20 Снимок экрана 2020-06-01 в 22.44.16.png13.14 KBkostyashupenko
#19 3138440-19-interdiff.patch84.24 KBmherchel
#19 3138440-19-full.patch85.9 KBmherchel
#18 3138440-18-full.patch85.92 KBmherchel
#18 3138440-18-interdiff.patch84.21 KBmherchel
#16 3138440-16.patch63.92 KBmherchel
#16 interdiff-without-dist.patch8.19 KBmherchel
#8 interdiff_6-8.txt48.01 KBkostyashupenko
#8 3138440-8.patch63.47 KBkostyashupenko
#7 firefox forms high contrast.png145.46 KBmherchel
#7 generic form.png29.83 KBmherchel
#6 Снимок экрана 2020-05-25 в 12.34.51.png58.14 KBkostyashupenko
#6 Снимок экрана 2020-05-25 в 12.34.45.png30.61 KBkostyashupenko
#6 interdiff_3-6.txt2.88 KBkostyashupenko
#6 3138440-6.patch44.37 KBkostyashupenko
#3 Без имени-1.jpg32.42 KBkostyashupenko
#3 Снимок экрана 2020-05-22 в 12.36.26.png27.92 KBkostyashupenko
#3 Снимок экрана 2020-05-22 в 12.36.19.png10.89 KBkostyashupenko
#3 Снимок экрана 2020-05-22 в 12.51.46.png96.51 KBkostyashupenko
#3 3138440-3.patch43.22 KBkostyashupenko

Comments

mherchel created an issue. See original summary.

kostyashupenko’s picture

Assigned: Unassigned » kostyashupenko
kostyashupenko’s picture

Provided patch was done agains 8.x-1.x-dev branch

I restored form styles before your commit and some changes has been re-added again, based on your commit @mherchel:

1. New box-shadow on focus state for boolean elements:

/* variables.css */
 --shadow-focusable-secondary: 0 0 0 2px #fff, 0 0 0 5px var(--color--blue-70);
/* form-boolean.css */
box-shadow: var(--shadow-focusable-secondary);

2. Right margin for inline boolean group:

/* form-boolean.css */
.form-boolean-group .form-type--boolean {
  &:not(:last-child) {
    .container-inline & {
      margin-right: var(--sp);
    }
  }
}

3. Also this construction was added by me to make textarea look better in MS Edge:

/* form-textarea.css */
.form-element--type-textarea {
  @media screen and (-ms-high-contrast: active) {
    &,
    &:hover,
    &:focus {
      background-image: none;
    }
  }
}

Now i have some things to be discussed.
Globally i just restored form components how it was before your commit @mherchel and just few lines were added (from three points i defined above).

Quote 1: Because this is a user facing theme, we have the use case where users may be inserting third party scripts (for example a mailchimp signup form) into their content. This should be themed.

In my patch i still keep classNames and not attributes as you defined, because:
1. I quickly tested mailchimp signup form and i didn't see any problems. I just have added API key from my account on mailchimp into mailchimp conf page (/admin/config/services/mailchimp) and then i have created a new Mailchimp Signup Form. Check the screen below:
mailchimp signup form

so as you said (for example a mailchimp signup form), please tell me if i did smth wrong. I really don't have too much experience with mailchimp and its configurations. Maybe some steps to reproduce case when form-elements are styled wrong?

2. Look at this table https://specifishity.com/ - Using of classnames has lower specificity than using attributes. I quickly have tested in browser - and it is really like this. That means (ideally) - any 3rd party libraries will not have any problems with its own styles and overrides of common styles of Olivero theme.

So for now i keep .form-element { ... } and not

input[type="text"],
input[type="search"],
input[type="email"],
input[type="password"],
input[type="number"],
input[type="tel"],
textarea,
.form-text {

Please explain me if i'm wrong and share your ideas why classnames shouldn't be used with illustrations maybe / steps to reproduce.

Quote 2: Focus states were not very apparent in Windows high contrast mode

Well, as i said - some styles for form-elements for Windows High Contrast mode already were added in first implementation. I again had a quick look on it and globally all is fine. Check 2 screens below:

Default
Windows high contrast default field

Focus
Windows high contrast focus field

So as you can see outline 2px is already there. Can you please tell me why it is not enough for you and what did you mean with Accessible. This means that borders, and focus states need to be visible in Windows high contrast mode.

Can you please illustrate maybe something or just tell me what do you think should be improved? This outline exist for any form element in MS Edge and Explorer.

Browsers i used:
Mac Firefox + Safari + Chrome / Real Windows IE11 + MS Edge / Virtual IE11 + MS Edge (from link in task description for virtual box)

===========

Btw, i really like new box-shadow for radio elementsOlivero radios

mherchel’s picture

My main concern is the noticeability of the focus states in high contrast mode. I'm going to ping the accessibility maintainers in the #accessibility channel in Drupal slack to weigh in.

mherchel’s picture

Some comments from https://drupal.slack.com/archives/C2ANFUGGG/p1590154141261800

R Mazur:

I've got pretty good eyes and I couldn't see it before I read what it was. ¯\_(ツ)_/¯

rain:

It is quite subtle. It may be worth exploring more obvious treatments

andrewmacpherson:

These technically pass WCAG SC 2.4.7 Focus Visible... in the letter of the law.

andrewmacpherson:

But I think they're poor too.

andrewmacpherson:

The dotted outline isn't any thicker than the exisitng line, and it directly adjoins the existing line. So the overall effect is that it changes from a crisp line, to a somewhat fuzzy line.
Suggested improvements (use more than one):

  • Use an outline-offset of a couple of pixels, so it becomes a double line. Unfortunately outline-offset doesn't work in IE. The effect can be implemented with an absolutely positioned ::after:focus box.
  • Use something more substantial as the focus line. Solid or dashed is stronger than dotted.
  • Use a thicker outline, so the overall shape change is just bigger

andrewmacpherson:

Like Rain an RMazur say, it's too subtle. Subtle just doesn't work for focus styles.

andrewmacpherson:

Windows high-contrast is effectively assistive tech, which someone decides to turn on. If they turned on Win HC, they almost certainly have an impairment such as:

  • low vision
  • attention difficulties
  • dyslexia (shape recognition plays a role here)
  • Washed out ambient light
kostyashupenko’s picture

outline-offset was added, also changed outline-style to "solid" and outline-width now bigger.

MS Edge with high contrast mode enabled:
Ms edge

IE11 with high contrast mode enabled:
IE11

mherchel’s picture

Status: Needs review » Needs work
StatusFileSize
new29.83 KB
new145.46 KB

This is great work! I've found a couple issues

1) testing generic form styling (there isn't much)
2) in Firefox in Windows high contrast mode. Note that accessibility maintainer @andrewmacpherson specifically called out this use case in previous issues.

Below is a screenshot from a mailchimp form embedded within a site running Olivero. We expect the form elements to be styled.

Below is screenshot from Firefox in high contrast mode. Focus states are good, but there are no left/right borders. This is confusing (the labels almost look like placeholders...). In addition the select element does not have a down arrow.

kostyashupenko’s picture

Status: Needs work » Needs review
StatusFileSize
new63.47 KB
new48.01 KB

Well.. i have a bad news.

First of all - i agree with you, we may get issues with embedded forms, so i did replace of `.form-element {}` based selectors by `attributes` as you suggested in your patch.

Second thing about firefox - i see no ways to fix reported issue with current implementation of form styles. There is no any detection of high-contrast mode for firefox in terms of CSS media queries. Styles looks so bad with firefox, and no linear-gradients, no background-images, and many other.
I see only 1 way to make it look better in firefox high contrast mode - is to transform background: linear-gradient() into borders as you suggested in your patch @mherchel, but as you remember - if we will use only borders, we will face with unexpected movement of elements on hover states. Some of these unexpected movements possible to fix - some of them not possible to fix too.

I see no other options.
Gonna summarize:
1. Or we keep current implementation of form elements where these form elements looks well styled and only (or mostly only) bugs in Firefox with enabled high contrast mode.
2. Or we need to redo all form-elements as you suggested in your patch (with border css-property, instead of linear-gradients) - after that issue with firefox with HCM enabled will be fixed, but some unexpected movement of text inside for example "type file" inputs, or text of textarea, or right bottom angle (resize icon) of textarea - we will face in all browsers.

mherchel’s picture

yeah.. I really struggled with FF in high contrast mode with the search form (and there has since been a regression).

I fear leaving FF high contrast broke is a non-starter for inclusion in Drupal 8 core. The accessibility gate is very stringent (which is a good thing).

I'll hack away at your patch later today. What I did earlier is shrink padding on focus to account for the border width. There may be other options too (such as setting box-sizing to content-box) that we can experiment with. The hard part is all of these old browsers in esoteric use-cases... but this theme will (hopefully) be used by so many people that we need to do our best to account for it.

Thanks so much for working on this.

kostyashupenko’s picture

Yup, let me review your changes please before merge

mherchel’s picture

Issue tags: +olivero_alpha_2
mherchel’s picture

I found the magical combination that works with everything. Tested in high contrast with IE11, Edge 44, and FF 76. Also seems to work in Chrome, Safari in normal use cases without shifting layout:

input {
  outline: solid 1px transparent;

  &:focus {
    outline: 4px solid transparent;
  
    @supports (outline-style: double) {
      outline-style: double;
    }
  }
}
mherchel’s picture

Status: Needs review » Needs work

Gonna hack at this today. Not sure I have much time to do so.

mherchel’s picture

Ended up changing the focus outline to dashed. It's much more apparent.

Also, note that the multiple backgrounds with linear gradients do not work in FF in high contrast mode.

 background:
    var(--form-element-select-icon) no-repeat right var(--form-element-select-icon-right-offset) top var(--form-element-select-icon-top-offset),
    linear-gradient(to right, var(--color--gray-30) var(--form-element-border-size-left), transparent var(--form-element-border-size-left), transparent 100%),
    linear-gradient(to left, var(--color--gray-30) var(--form-element-select-border-size-right), transparent var(--form-element-select-border-size-right), transparent 100%) var(--color--gray-95);

However, the single background image of the chevron works fine.

  background:
    var(--form-element-select-icon) no-repeat right var(--form-element-select-icon-right-offset) top var(--form-element-select-icon-top-offset);
mherchel’s picture

A couple notes about getting the select element to render properly in FF in high contrast mode:

Firefox will not render any background image if one of them has a linear gradient. This means we cannot use linear gradients where we need the chevron (because the only way that we can render the chevron is via a background image)

We cannot use box-shadow inset to render the background of the chevron... it appears in front of it and obscures it.

The only way that I found to render the solid background of the chevron is by calling another image (a small svg).

:root {
  --form-element-select-icon: url("../../../images/chevron-down.svg");
  --form-element-select-bg: url("../../../images/select-chevron-bg-default.svg");
  --form-element-select-bg--highlight: url("../../../images/select-chevron-bg-highlight.svg");
}

select {
  background:
    var(--form-element-select-icon) no-repeat right var(--form-element-select-icon-right-offset) center,
    var(--form-element-select-bg) no-repeat right 0 top 0,
    var(--form-element-select-bg) no-repeat left -48px top 0;

  &:hover,
  &:focus {
    background:
      var(--form-element-select-icon) no-repeat right var(--form-element-select-icon-right-offset) center,
      var(--form-element-select-bg--highlight) no-repeat right 0 top 0,
      var(--form-element-select-bg--highlight) no-repeat left -48px top 0;
  }
}

Note I'm using the same exact SVG to render the left border. This is because if I use the "border-left" property, the top and the bottom of the borders are angled to blend with the transparent top and bottom borders.

mherchel’s picture

StatusFileSize
new8.19 KB
new63.92 KB

Adding some updated patches. Note the interdiff doesn't include the css/dist directory.

Still lots of work to do including error and disable statuses on select elements as well as the small version of that. But everything's working overall. Just needs lots of cleanup.

mherchel’s picture

Assigned: Unassigned » mherchel

Got a bit more work done in the error states. I'm going to work on this tomorrow also. I want to get this committed and release alpha2 on monday if at all possible.

mherchel’s picture

Status: Needs work » Needs review
StatusFileSize
new84.21 KB
new85.92 KB

I got everything working based off of the patch in #8. There were a lot of issues with FF in high contrast mode including text input focus states, select arrows, and radio and checkbox not showing the unchecked state properly.

Patches attached.

mherchel’s picture

StatusFileSize
new85.9 KB
new84.24 KB

I forgot to change the border color on the select element's focus state. Updated patches attached.

kostyashupenko’s picture

Thanks for killing this issue, i have tested your patch and it looks almost finished. I have tested high contrast mode in FF/IE/Edge and form-elements and its hover/focus states looks great. I also found 3 bugs:

1. There is a top 2px gray line on selects / default state. And text is not aligned vertically as you can see
selects

2. type="date" inputs has 56px of the height on google chrome (maybe other browsers too, i didn't check).
date

It comes from shadow dom elements, look at here -> this little string will fix the issue:
date fix

3. You have removed form-boolean--ie.css file, so now boolean form-elements looks un-styled in IE11:
form bool Ie11

mherchel’s picture

Status: Needs work » Needs review
StatusFileSize
new91.72 KB
new29.97 KB

Updating patch and interdiff!

I personally think the IE11 styling is fine. It's completely usable.

kostyashupenko’s picture

Hello @mherchel
i have tested your patch and issue number 1 still exist ("text is not aligned vertically" <- this part actually only). So you can fix it looks like by decreasing line-height for selects. Rests things are ok

kostyashupenko’s picture

Status: Needs review » Needs work

Also not sure if related, but git apply -v [your-last-patch] gives:

        deleted:    config/optional/block.block.olivero_search_form_narrow.yml
	deleted:    config/optional/block.block.olivero_search_form_wide.yml
	deleted:    config/optional/image.style.olivero_hero.yml
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	config/install/block.block.olivero_search_form_narrow.yml
	config/install/block.block.olivero_search_form_wide.yml
	config/install/image.style.olivero_hero.yml
mherchel’s picture

yeah, the config changes snuck in the patch.

I missed the part about text not being aligned vertically. Fix incoming.

mherchel’s picture

Status: Needs work » Needs review
StatusFileSize
new90.27 KB
new1.56 KB

Updating patches to take into account the centering the text. Note the interdiff doesn't include removing the config.

kostyashupenko’s picture

-  line-height: var(--form-element-select-height);
+  line-height: calc(var(--form-element-select-height) - var(--form-element-border-size-base));

It looks like expected line-height should be the following:
line-height: calc(var(--form-element-select-height) - 2 * var(--form-element-border-size-base));

since top border + bottom border

mherchel’s picture

StatusFileSize
new55.99 KB

Decreasing the line-height causes some vertical alignment issues. Conceptually, you're correct, though. I think it's because the font isn't rendering in the center of its line-height. Not 100% sure though.

I'm committing as-is, we can follow up if we find a better way.

mherchel’s picture

Status: Needs review » Fixed

Committed this. Let's open up a followup if the select is out of alignment, or if there's a better way to do it.

andypost’s picture

Status: Fixed » Needs work
Issue tags: +Needs followup

@mherchel it still needs follow-up for #28

mherchel’s picture

@andypost are you seeing the select elements out of alignment? If so, what browsers?

kostyashupenko’s picture

Status: Needs work » Fixed

I will create a follow-up right now

kostyashupenko’s picture

andypost’s picture

Issue tags: -Needs followup

Thank you!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.