As mentioned in commit 5214d89c8, using a `<select>` tag which
automatically submits a form on change has a few accessibility issues,
particularly for keyboard users who might accidentally submit the form
while browsing the options.
So we're adding a submit button and removing the "submit on change"
behavior.
Note that, while `<select>` tags have their own usability issues,
alternatives in this case are not obvious because the number of existing
polls could be very low (zero, for instance) or very high (dozens, if
the application has been used for years).
I thought of using a `<datalist>` tag with a regular text input. The
problem here is we don't want to send the name of the poll to the server
(as we would with a `<datalist>` tag); we want to send the ID of the
poll.
Maybe we could add an automplete field instead, providing a similar
funcionality. However, for now we're keeping it simple. This poll
questions page isn't even accessible through the admin menu since commit
83e8d603, so right now anything we change here will be pretty much
useless.
There are two bugs in Internet Explorer which caused our footer to be
rendered incorrectly.
First, the `flex: 1` property doesn't work so well when `flex-direction`
is set to `column`. We're replacing it with `flex-grow: 1`. No need to
set other `flex-basis` nor `flex-shrink` in this case since in this case
the default values will work just fine.
Second, it didn't handle the body height being set to `100%` so well,
and the footer was rendered after that 100% point, even if the content
still continued.
So we're using `min-height` instead, which is actually a bit more
accurate (since the body is usually taller than the document root
element). This causes a different issue since on IE the `flex-grow: 1`
property becomes useless. This will only affect IE users with very large
screens, though, and it's way better than rendering the footer
overlapping the main content, so we can live with that. The page won't
look as great as in other browser, but it will still be usable.
This way it's possible to customize these colors by just changing a
variable.
The code is now quite a bit hacky; since I'm not an expert in color
design, I didn't want to change the colors we were using in case it made
the application have less appeal.
If slightly changing these colors isn't a problem, we could use
Foundation's defaults to simplify the code, maybe just changing the
`$table-color-scale` variable.
We're using `background: #fff` and `background: $white` in many places.
Sometimes we mean "use the same background as the body", which means if
we change the body background so it's, let's say, dark, we'll also have
to change all these places.
So now we're using `$body-background` in more places, so changing the
general background color is easier.
There are still some places where we use `#fff` or `$white`. Sometimes
it's hard to tell whether the intention is "use a white background here"
or "use the same background as the body here". When in doubt, I've left
it the way it was.
Just for testing purposes, I've tested locally how things would look
like if we added this code to `_consul_custom_overrides.scss`:
```
$body-background: #fea;
$card-background: $body-background;
$tab-background: $body-background;
$tab-content-background: $body-background;
$table-background: $body-background;
```
Or:
```
$body-background: #333;
$text: #fcfcfc;
$body-font-color: $text;
$card-background: $body-background;
$tab-background: $body-background;
$tab-content-background: $body-background;
$table-background: $body-background;
```
Testing shows we've still got a long way to go to make it easy to add
custom color themes, since there are many custom colors in the code.
Hopefully these changes bring us one step closer.
These elements already inherit these background colors form their parent
elements. Defining them explicitly makes it harder to change them and it
also makes it harder to customize the styles in other CONSUL
installations.
The `include_all` parameter was always used, and the option was
redundant because we already had a prompt offering the same
functionality.
I guess one possible reason was users would want to filter by all polls,
and having to click on "select a poll" to do so wasn't that intuitive.
So we're using "All" as the prompt instead.
We were using Font Awesome fonts and selectors to support the browsers
which don't support mask images (at the time of writing, about 5% of the
browsers). However, we were only importing the selectors in order to
extend them. This resulted in our compiled CSS including styles for
every Font Awesome icon (currenty, more than a thousand), even if we
only use a few of them.
So we're using Font Awesome variables instead of using the selectors it
provides. Since variables are only compiled in the CSS if they're
actually used, this reduces the size of our compiled CSS considerably.
In production environments, the size is reduced from 539KB to 475KB,
meaning we reduce its size in about 12%.
The downside here is we can't easily use Font Awesome variables in our
Sass mixins because we can't use interpolation in variable names (that
is, we can't use `$fa-var-#{icon}`). So we're using a map containing all
Font Awesome variables in order to access it in the mixin.
Note installations using `.fa-*` selectors will now have to add extra
`@import` clauses.
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
