Using the `document` or `documents` classes meant styles defined for the
public list of documents conflict with these ones.
So now we're using HTML classes that match the name of the Ruby
component classes, as we usually do.
This way we make it easier to modify.
Note that, since the title of the page is "Administration" and it's in
the "Admin" section, we're adding an option to the `header` method in
order to avoid having a confusing title like "Administration - Admin".
Also note that, by removing the `title` HTML class, we avoid inheriting
styles from the `dashboard.scss` stylesheet, and now the heading is
displayed in the position it was meant to.
Finally, the concept of using a `main-class` for the current page comes
from a branch (currently in development) which will replace the <div>
tag with the `admin-content` class with a `main` tag.
The Web Content Accessibility Guidelines version 2.1 added a success
criterion called Non-text Contrast [1], which mentions that the focus
indicator must contrast with the background, and version 2.2 introduced
a specific one regarding focus appearance [2]. According to that
criterion, the focus indicator:
* is at least as large as the area of a 2 CSS pixel thick perimeter of
the unfocused component or sub-component
* has a contrast ratio of at least 3:1 between the same pixels in the
focused and unfocused states.
Our current solution for highlighting elements on focus has a couple of
issues:
* It doesn't offer enough contrast against the default white background
(1.6:1)
* It offers even less contrast against other backgrounds, like the
homepage banner or the featured proposals/debates
Making the color of the outline darker would increase the contrast
against these backgrounds, but it would reduce the contrast against
other backgrounds like our default brand color.
For this reason, most modern browsers use a special double outline with
two different colors [3], and we're choosing to combine an outline and a
box shadow to emulate it, using the brand color as the second color.
However, this double-colored outline doesn't work so well when focusing
on dark buttons surrounded by a light background, so instead we're using
a triple outline, which works well on any color combination [4]. Since I
feel that making the third outline 2px wide makes the overall outline
too wide, I'm making the inner outline just 1px wide since that's enough
to prevent edge cases.
Note that Foundation adds a transition for the `box-shadow` property on
`select` controls, which gets in the way of the focus we use on the
language selector. So we're removing the transition.
Also note that the box-shadow style didn't work properly with the
box-shadow we added on the `:hover` status on cards, so we're changing
the code in order to cover this case.
Finally, note that the box-shadow isn't displayed properly on multiline
links (in Chrome, not even with `box-decoration-break: clone`), like the
ones in debates/proposals/polls/investments/processes titles, so we're
changing the style of these links to `inline-block`.
[1] https://www.w3.org/TR/WCAG21/#non-text-contrast
[2] https://www.w3.org/TR/WCAG22/#focus-appearance
[3] https://www.sarasoueidan.com/blog/focus-indicators/#examining-(current)-browser-focus-indicators-against-wcag-requirements
[4] https://www.erikkroes.nl/blog/the-universal-focus-state/
The `inverted-selection` rules defined in the `%brand-background`
selector weren't being applied because we were using this selector in
`::before` and `::after` pseudoelements. Not sure about the reason, but
it looks like the saturation of `::after::selection` pseudoelements
resulted in invalid selectors and so the inverted selection rules were
ignored for every selection using `%brand-background`, like
`%budget-header`.
Using `@include brand-background` instead of `@extend %brand-background`
in pseudoelements solves the issue. The inverted selection might not
work in these pseudoelements, but we don't need it there since these
pseudoelements don't have content.
Some institutions using CONSUL have expressed interest in this feature
since some of their tenants might already have their own domains.
We've considered many options for the user interface to select whether
we're using a subdomain or a domain, like having two separate fields,
using a check box, ... In the end we've chosen radio buttons because
they make it easier to follow a logical sequence: first you decide
whether you're introducing a domain or subdomain, and then you enter it.
We've also considered hiding this option and assuming "if it's got a
dot, it's a domain". However, this wouldn't work with nested subdomains
and it wouldn't work with domains which are simply machine names.
Note that a group of radio buttons (or check boxes) is difficult to
style when the text of the label might expand over more than one line
(as is the case here on small screens); in this case, most solutions
result in the second line of the label appearing immediately under the
radio button, instead of being aligned with the first line of the label.
That's why I've added a container for the input+label combination.
Until now, overwriting the styles for a certain tenant was a very
tedious task. For example, if we wanted to use a different brand color
for a tenant, we had to manually overwrite the styles for every element
using that color.
It isn't possible to use different SCSS variables per tenant unless we
generate a different stylesheet per tenant. However, doing so would make
the CSS compilation take way too long on installations with more than a
couple of tenants, and it wouldn't allow to get the colors dynamically
from the database, which we intend to support in the future.
So we're using CSS variables instead. These variables are supported by
97% of the browsers (as of October 2022), and for the other 3% of the
browsers we're using the default colors (SCSS variables) instead.
CSS variables have some limitations: for instance, it isn't possible to
use functions like `lighten`, `darken` or `scale-color` with CSS
variables, so the application might behave in a strange way when we use
these functions.
It also isn't possible to automatically get whether black or white text
makes a better contrast with a certain background color. To overcome
this limitation, we're providing variables ending with `-contrast`. For
instance, since the default `$brand` color is a dark one, when assigning
a light color to `--brand`, we probably want to assign
`--brand-contrast: #{$black}` as well, so the text is still readable.
This way we simplify the code a bit.
Note we're only using this function when variables for background colors
are already defined, since that means customizing the variable using the
background color will automatically change the color of the text.
Customization isn't easier when using raw colors.
We were defining (for instance) white text against the `$brand`
background. That meant that, if somebody customized the `$brand` color
so it used a light color, they had to customize the text color as well
in order to guarantee proper contrast between text and background
colors.
So we're using `color-pick-contrast` instead, which means we don't have
to manually calculate whether white or black will be the color which
makes the text more readable.
Add a help text on admin budget show page and improve text from Admin::Budgets::HelpComponent in order to
clarify its functionality when we are using the wizard.
Captions benefit blind screen reader users who navigate through tables,
particularly in this case because we potentially have several tables
with headings (one table per group), so when navigating through tables
it might be hard to know which group the headings belong to.
In this case they also benefit sighted users. Usability tests have shown
the "Groups and headings" section is a bit confusing, so adding a
caption like "Headings in Districts" helps clarifying Districts is a
group and the table refers to headings in that group.
The very same table is rendered in the "headings" step of the budget
creation wizard. However, in that case the information of the caption is
redundant because the page is specific for headings belonging to a
certain group. We're making the element invisible but still keeping it
for screen reader users in order to ease their navigation through
tables.
The problem of having actions next to the title is that, when there are
titles of very different lenghts, at certain resolutions some actions
will be next to their titles (because there'll be space for everything)
but some actions will be below their titles. This makes it hard for
people to follow where the actions are.
The buttons to create polls associated with a budget were too prominent,
appearing on the table as if they were as used as the link to manage
investments. Most CONSUL installations don't use physical booths, and
would probably wonder what that button is about.
We're moving it to a more discrete place, at the bottom of the budget
page. This way we can also split the action in two: on budgets not
having a poll, we display the button in a not-so-accessible position (at
the bottom of the page), since this button will only be used once per
budget at most. Once the poll has been created, it means this feature is
going to be used, so we display a link to manage ballots more
prominently at the top of the page. If the budget has finished the final
voting stage without creating a poll, we don't show either the link or
the button because this feature can no longer be used.
We're also adding some texts indicating what this feature is about,
since it's probably one of the least understood features in CONSUL
(probably because the interface is very confusing... but that's a
different story).
Since now from the budget page we can access every feature related to
the budget, we can remove the "preview" action from the budgets index
table, since this feature isn't that useful for budgets once they're
published.
Now the budgets table doesn't take as much space as it used to, although
it's still too wide to be handled properly on devices with a small
screen.
Since managing investments is a very common action, with this link
administrators won't have to go back to the index page to manage
investments; they can access it from either the budgets index page or
the budget page.
Since now the links we've got on the budget page are similar to the ones
we've got in the index page table, we're styling them in a similar way.
We're also fixing a small typo en the investments path; it works exactly
the same way as it used to, but passing `budget` instead of `budget_id:
budget.id` is shorter and more consistent with what we do in other
places.
Both the calculate winners and delete actions benefit from some kind of
hint.
The "calculate winners" hint informs administrators that results won't
be publicly available unless the "show results" option is enabled.
The delete action was redirecting with an error message when the budget
couldn't be deleted; IMHO it's better to disable it and inform
administrators why it's disabled. Alternatively we could remove the
button completely; however, users might be looking for a way to delete a
budget and wouldn't find any hint about it.
We're now removing the "Delete" action from the budgets index table,
since most of the time it isn't possible to delete a budget and so the
action takes up space and we get little gain in return. We could keep
the "Delete" icon just for budgets which can be deleted; however, the
alignment of the table rows would suffer, making it harder to find the
intended action.
Before, users needed to navigate to the list of groups in order to
add, edit or delete a group.
Also, they need to navigate to the list of groups first, and then to
the list of headings for that group in order to add, edit or delete a
heading.
Now, it's possible to do all these actions for any group or heading
from the participatory budget view to bring simplicity and to reduce
the number of clicks from a user perspective.
Co-Authored-By: Javi Martín <javim@elretirao.net>
In the past it would have been confusing to add a way to directly
enable/disable a phase in the phases table because it was in the middle
of the form. So we would have had next to each other controls that don't
do anything until the form is sent and controls which modify the
database immediately. That's why we couldn't add the checkboxes we used
when using the wizard.
Now the phases aren't on the same page as the budget form, so we can
edit them independently. We're using a switch, so it's consistent with
the way we enable/disable features. We could have used checkboxes, but
with checkboxes, users expect they aren't changing anything until they
click on a button to send the form, so we'd have to add a button, and it
might be missed since we're going to add "buttons" for headings and
groups to this page which won't send a form but will be links.
Since we're changing the element with JavaScript after an AJAX call, we
need a way to find the button we're changing. The easiest way is adding
an ID attribute to all admin actions buttons/links.
Having links in the middle of a form distracts users from the task of
filling in the form, and following a link before submitting the form
will mean whatever has been filled in is lost.
And the budgets form is already very long and hard to fill in. Having
the phases table in the middle of it made it even harder. And, since
we're planning to add the option to manage groups and headings from the
same page, it's better to have a dedicated page for the form.
Since we aren't very consistent in the styles for submit buttons in the
admin section, it was possible to accidentally press the "Calculate
Winner Investments" link after filling in the form. This wouldn't submit
the form and so the changes wouldn't be saved.
It's also a bit confusing for users. After filling in a form, users
expect a submit button. When finding two buttons, they've got to stop to
think which one is the one they've got to press.
Furthermore, the "Calculate Winner Investments" link would work better
as a button instead of a link, for the reasons mentioned in commit
5311daadf. Since HTML forms can't be nested, that would mean treating
this button in a different way than the rest of the buttons in the
application.
Moving the link before the form solves the issue.
Since now we've got the budget actions before the budget form, we're
grouping these actions together with the "Preview" action. We're not
adding the "Publish budget" button as well to this group because it's
got an associated message.
This way we remove duplication and it'll be easier to add better support
for RTL languages.
In a few years this might not be necessary since support for the `gap`
property in a flexbox layout will improve. At the time of writing,
however, only 86.5% of the browsers support it [1].
[1] https://caniuse.com/flexbox-gap
As mentioned in commit b7f6c4c43:
> [In Internet Explorer] 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`
> since in this case the default values will work just fine.
On very large screens, the admin menu had a lot of blank space for
languages where all sections had short names (like English). This was
inconvenient because the icon to open a submenu was far from its
associated menu item.
Using the `max-content` value for the `max-width` property, we reduce
the amount of blank space in these cases.
Since the icon was absolutely positioned, in some languages it
overlapped with the text.
Using a flex layout solves this issue. It also improves the appearance
of elements whose text spans over multiple lines; previously the second
line would go under their section icon.
We're also using the `$global-left` variable so the icon is properly
displayed in languages written from right to left. We could use the
`margin-inline-start` property instead, but it isn't universally
supported in every browser yet.
Since the layout is now incompatible with the old (and obsolete) way to
add icons to the menu (using classes which would use the
`[class^="icon-"]` selector), we're removing this code.
When items went over multiple lines, the distance between their lines
was the same as the distance between one element and another one. This
made it hard to differentiate how many elements there were.
Using a padding to separate the contents of one element and the contents
of the next one solves the issue.
We were using buttons with the "Enable" and "Disable" texts to
enable/disable settings. However, when machine learning settings were
introduced in commit 4d27bbeba, a switch control was introduced to
enable/disable them.
In order to keep the interface consistent, we're now using switch
controls in other sections where settings are enabled/disabled. We can
even use the same code in the machine learning settings as well.
We're also removing the confirmation dialog to enable/disable a setting,
since the dialog is really annoying when changing several settings and
this action can be undone immediately. The only setting which might need
a confirmation is the "Skip user verification" one; we might add it in
the future. Removing the confirmation here doesn't make things worse,
though; the "Are you sure?" confirmation dialog was also pretty useless
and users would most likely blindly accept it.
Note Capybara doesn't support finding a button by its `aria-labelledby`
atrribute. Ideally we'd write `click_button "Participatory budgeting"`
instead of `click_button "Yes"`, since from the user's point of view the
"Yes" or "No" texts aren't button labels but indicators of the status of
the setting. This makes the code a little brittle since tests would pass
even if the element referenced by `aria-labelledby` didn't exist.
There were times when some actions had text expanding over two lines
while other actions had text on just one line.
Since all the items in a row had the same height, the elements with just
one line added a blank second line. This was obvious when hovering with
the mouse or focusing on the element with the keyboard. It looked weird
when the element received focused, and it could also lead to
unintentional clicks when clicking on the blank space below the element.
The underline text decoration looked a bit strange with the icon on top
of it, and we had an inconsistency since links had a text decoration but
buttons didn't. I think we can remove it since both the color of the
icon and the cursor change on hover and that's enough feedback.
And we were accidentally overwriting the color of the investments link
on hover and focus.
By default, Rails disables submit inputs (<input type="submit">) when
they're pressed so we avoid a double-submission when users click the
button twice.
However, Rails does not disable submit buttons (<button type="submit">)
when they're pressed. This means there's a chance users might press the
button several times. Even if most our table actions are idempotent, it
might cause certain issues. For instance, pressing the "Delete" button
twice means the second request might raise an
`ActiveRecord::RecordNotFound` exception.
Disabling the button also gives feedback to users, letting them know
they've correctly clicked the button.
Links acting like buttons have a few disadvantages.
First, screen readers will announce them as "links". Screen reader users
usually associate links with "things that get you somewhere" and buttons
with "things that perform an action". So when something like "Delete,
link" is announced, they'll probably think this is a link which will
take them to another page where they can delete a record.
Furthermore, the URL of the link for the "destroy" action might be the
same as the URL for the "show" action (only one is accessed with a
DELETE request and the other one with a GET request). That means screen
readers could announce the link like "Delete, visited link", which is
very confusing.
They also won't work when opening links in a new tab, since opening
links in a new tab always results in a GET request to the URL the link
points to.
Finally, submit buttons work without JavaScript enabled, so they'll work
even if the JavaScript in the page hasn't loaded (for whatever reason).
For all these reasons (and probably many more), using a button to send
forms is IMHO superior to using links.
There's one disadvantage, though. Using `button_to` we create a <form>
tag, which means we'll generate invalid HTML if the table is inside
another form. If we run into this issue, we need to use `button_tag`
with a `form` attribute and then generate a form somewhere else inside
the HTML (with `content_for`).
Note we're using `button_to` with a block so it generates a <button>
tag. Using it in a different way the text would result in an <input />
tag, and input elements can't have pseudocontent added via CSS.
The following code could be a starting point to use the `button_tag`
with a `form` attribute. One advantage of this approach is screen
readers wouldn't announce "leaving form" while navigating through these
buttons. However, it doesn't work in Internet Explorer.
```
ERB:
<% content_for(:hidden_content, form_tag(path, form_options) {}) %>
<%= button_tag text, button_options %>
Ruby:
def form_id
path.gsub("/", "_")
end
def form_options
{ id: form_id, method: options[:method] }
end
def button_options
html_options.except(:method).merge(form: form_id)
end
Layout:
<%= content_for :hidden_content %> # Right before the `</body>`
```
We were using a focus outline on links, but weren't doing the same for
buttons. Since sometimes browsers use a default outline which is barely
visible, this was very disorienting when browsing using the keyboard; we
were navigating through links that clearly indicated where the keyboard
focus was, and when reaching a button suddenly we had this almost
imperceptible feedback. Even if I'm used to it, my first reaction is
always "where did the focus go?" until I realize it's now on a button.
This is even more confusing because we've got buttons looking like links
and links looking like buttons.
Note that in the rules for the `:focus` styles we're including buttons
and the `[type="button"]` attribute. This seems redundant since those
styles are already covered by the `button` selector. However, Foundation
adds styles to buttons with the `[type]` attribute. Since the attribute
selector has precedence over the tag selector, we need to use the
attribute selector as well in order to override Foundation's styles.
It was broken since we fixed issues with other image fields in commit
394a94cbf, because there we added a fieldset for the image fields, and
so they inherited the styles in budget phases fields (these styles were
added before it was possible to attach an image to a phase).
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.
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/
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;
}
```
