When we see a list of, let's say, banners, and each one has a link to
edit them, the word "banner" in the text "edit banner" is redundant and
adds noise; even for users with cognitive disabilities, it's obvious
that the "edit" link refers to the banner.
In commit 9794ffbbf, we replaced "buttons" with icons in order to make
the admin interface consistent with the planned budget investments
redesign.
However, using icons has some issues. For once, icons like a trash for
the "delete" action might be obvious, but other icons like "confirm
moderation" or "send pending" might be a bit confusing.
It's true that we were adding tooltips on hover. We tried two
approaches: using Foundation's tooltips and using CSS tooltips.
Foundation tooltips are not activated on focus (only on hover), while
CSS tooltips always appear below the icon, which might be a problem when
the icons are at the bottom of the screen (one of our milestone tests
was failing because of that and we can now run it with JavaScript
enabled).
Both Foundation and CSS tooltips have other issues:
* They force users to make an extra step and move the mouse over the
link just to know what the link is about
* They aren't available on touch screens, so these users will have to
memorize what each icon does
* They are not hoverable, and making them hoverable would cause a
different issue because the tooltip might cover links below it, making
it impossible to click these links without moving the mouse away
first
* They are not dismissable, which is considered an accessibility issue
and a requirement in the Web Content Accessibility Guidelines [1]
For all these reasons, we're using both texts and icons. As Thomas
Byttebier said "The best icon is a text label [2]". Heydon Pickering
also makes a point towards providing text alongside icons in his book
"Inclusive Components" [3].
Note that, since we're now adding text and some of the colors we use for
actions are hard to read against a white/gray background, we're making a
few colors darker.
With these changes, actions take more space in the admin table compared
to the space they took in version 1.3, but they are more usable and
accessible while they still take less space than they did in version
1.2.
[1] https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus
[2] https://thomasbyttebier.be/blog/the-best-icon-is-a-text-label
[3] https://inclusive-components.design/tooltips-toggletips/
As mentioned in commit 5214d89c8, there are several issues with
submitting a form when a `<select>` tag changes. In particular, keyboard
users might accidentally fire the event while browsing the options, and
screen reader users will find a form with no obvious way to submit it.
In this case, there's an extra problem: in commit be8a0dbe8 we added a
second `<select>` field to this form, which also submitted on change.
Sometimes users changed one of the values and wanted to change the other
value as well before submitting the form. However, it wasn't possible,
because we would submit it before they had a chance to change the second
value.
So now we don't submit the form on change and add a submit button. This
is similar to what we do in the "Advanced filters" we use in several
places.
Using `currentcolor` is IMHO more expressive, since it shows the
intention of styling the border with the same color as the text.
This is particularly useful for CONSUL installations using custom
styles. Consider the following code:
```
.is-active {
border: 1px solid $brand;
color: $brand;
}
```
If we'd like to customize the way active items look, we'd have to
override two colors:
```
.is-active {
border: 1px solid $brand-secondary;
color: $brand-secondary;
}
```
Consider the scenario where we use `currentcolor` (which is the default
border color):
```
.is-active {
border: 1px solid;
color: $brand;
}
```
Now we only need to override one color to change the styles:
```
.is-active {
color: $brand-secondary;
}
```
Since we are using the same color as the text color in both the public
and admin areas, we can omit the border color completely. Since now
admin elements get the exact same border, we can remove this border so
they'll inherit the same border as used in the public area.
Since we're only changing the style of the border in one case and the
color in the other case, we don't have to duplicate the code for every
property.
This makes it easier for other CONSUL installations to customize these
borders.
By default Foundation uses a `#1779ba transparent transparent`
transparent border. We were overriding the whole border, when we only
needed to override the top border. Furthermore, we were overriding it
twice: once in the public area and once in the admin area. However, if
we use `currentcolor`, we only have to override it once, and in both
cases the border will have the same color as the text surrounding it
(white in the public area and black in the admin area).
Using `inherit` is IMHO more expressive since it means "use the color of
the parent element".
This is particularly useful for CONSUL installations using custom
styles. Consider the following code:
```
h2 {
color: $white;
a {
color: $white;
}
}
```
If we'd like to customize the way headings look, we'd have to override
two colors:
```
h2 {
color: $red;
a {
color: $red;
}
}
```
Consider the scenario where we use `inherit`:
```
h2 {
color: $white;
a {
color: inherit;
}
}
```
Now we only need to override one color to change the styles:
```
h2 {
color: $red;
}
```
Using the same color as text made it impossible to visually recognize
the link. Users might click the link accidentally while trying to select
the text of that link.
Furthermore, sighted keyboard users would be surprised when tabbing
through the interface and realizing some apparently normal text is
really a link.
Since commit dcec003d0 we're only using the menu-text class in the admin
layouts. So instead of defining styles for menu-text and then
overwriting them in the admin section, we can define them just in the
admin section.
Since we don't have <img> tags in the menu-text element in the admin
section, we can remove their styles. And we can also remove the styles
we were overriding twice (like `line-height`).
These styles aren't necessary since commit aabf8493f. Now the "Go back"
link in the budgets section can use the same color as in the other
sections, while the other texts inherit the usual colors.
Now that we load this file before loading the `_settings.scss` file, we
can safely use the `!default` flag.
This makes it easier to override these variables by adding a new file
and loading it before `_consul_settings.scss` is loaded. For instance,
we've got this code related to the `$brand` variable:
```
$brand: #004a83 !default;
$brand-secondary: darken($brand, 10%) !default;
$dark: $brand-secondary !default;
$link: $brand !default;
$debates: $brand !default;
$tooltip-background-color: $brand !default;
```
If we override `$brand` in `_custom_settings.scss`, variables like
`$link` won't be affected by this change. In order to do so, we'd need
to load `_custom_settings.scss` before loading `_consul_settings.scss`.
So why aren't we loading `_custom_settings.scss` first, just like we
load `_consul_settings.scss` before loading `_settings.scss`? Mainly,
compatibility reasons. Some people might have this code in their
`_custom_settings.scss` file:
```
$dark: darken($brand, 30%);
```
If we load this file before loading `_consul_settings.scss`, we'll get
an error because `$brand` isn't defined at this point.
So we're introducing a new file where variables can be overriden before
they are defined while keeping the option to override them after they
are defined.
We're updating the comments in these files to define the new behavior,
and removing the links (which point to places which don't exist since
commit 392d633d2) in order to make it easier to read the comments.
We were overriding these values because the `$body-font-family` and
`$global-radius` variables were defined after the values in the
`_settings.scss` file had been computed.
Now these values are defined before the values in the `_settings.scss`
are computed, so we don't need to override the values which depend on
them anymore.
We were loading all Foundation variables and then overriding them. This
is problematic because we were overriding variables after using them.
For instance, we had this code in `_settings.scss`:
```
$black: #0a0a0a;
$white: #fefefe;
$body-background: $white;
$body-font-color: $black;
```
That meant we were setting `$body-background` to `#fefefe`, and
`$body-font-color` to `#0a0a0a`. Even if we changed the values of
`$black` and `$white` later, `$body-background` and `$body-font-color`
were not affected by this change.
So now we're overriding `$black` and `$white` before setting
`$body-background` and `$body-font-color`. In order to keep our custom
values instead of overriding them, we're using the `!default` flag in
the `_settings.scss` file.
This way of defining variables in the `_settings.scss` file with the
`!default` flag is recommended in the documentation regarding the
settings file [1].
There's also a disadvantage to this approach. Now that we're loading the
`_consul_settings.scss` file first, we can no longer use Foundation
variables inside the `_consul_settings.scss` file unless we define them
in this file as well.
[1] https://get.foundation/sites/docs/sass.html#the-settings-file
Since we were using `position: absolute` to position the button to the
right, we were assuming there was enough screen space on the left so
other elements (mainly, order selector links) could be there.
However, that wasn't always the case. In some languages, the texts
appearing on the left of the button were much larger than in English,
meaning their text and the button text could overlap. Even in English,
users could experience the same issue depending on their font size
preferences and the size of their screens.
The easiest solution is to move the button to its own line, so its text
doesn't overlap.
Since forms are landmarks, screen reader users might navigate to the
form. But then they were going to find an empty form with no way to
toggle it.
Moving the button inside the form means screen reader users navigating
to the form will find the button to toggle it.
It also helps us simplifying the code; there's no need to use
data-attributes to communicate whether the form should be visible since
now we can easily use the button `aria-expanded` attribute.
We could further simplify the JavaScript if we used a CSS rule to
show/hide the form fields based on the toggle button `aria-expanded`
attribute. However, implementing the "slide" animation we use when
toggling the form with CSS is difficult and unreliable.
We were using the form and then showing it with JavaScript when advanced
search terms were present. Now we hide it with JavaScript when no
advanced search are present. This means users without JavaScript
(including users with JavaScript enabled but bad internet connections
preventing the JavaScript to load) can now access the form.
The other main difference between the two versions is the way the form
flashes while JavaScript is loading.
Previously, the form would always be hidden when no terms had been
introduced. However, when these terms were present, after submitting the
form it would briefly be hidden and then shown again.
Now the opposite happens. When advanced search terms are present, the
form is shown at all times. However, when they aren't, the form is
briefly shown before it disappears.
Here the previous behavior is arguably better because most of the time
these terms will not be present.
So basically we're significantly improving the experience of some users
at the cost of slightly worsen the experience of other users.
We're also hiding the button to show the form when JavaScript is
disabled, since in this scenario it's useless. We're using the `hidden`
attribute so hidden buttons can be detected in CSS.
