We don't need any row classes anymore because the <body> already has a
maximum width. As for columns, we only have one column in this form, so
we don't need them either. Besides, the form's parent element already
has a padding.
So they follow the same convention used in proposals.
Note the styles are for elements which appear in the "new" view but not
in the "edit" view, so we only have to include them in one place.
Since now categories are loaded in both the investment form component
and proposal form component, and their controllers are the only
"commentable" controllers using the `@categories` instance variable, we
can remove the `load_categories` call in `CommentableActions` affecting
the create and update actions.
One of them was less wide than the other one.
We're still only adding the heading to the form for the new investment,
just like in the original budgets redesign.
Using `flex` instead of a fixed width for the navigation, the elements
take all the available space when the search form isn't present. That
wasn't the case before and produced a strange effect on medium-sized
screens.
This way we also align the search to the right.
Since the top-bar already includes a layout positioning the elements,
these classes are redundant and actually confusing, since the element
floating to the right was on the left.
This solves a problem where the outline wasn't correctly displayed when
focusing on the logo using the keyboard. Firefox was displaying two
vertical lines together above the logo, while recent Chrome versions
displayed the outline to the right of the logo.
In the case of the public layout, the row element was originally there
so the content of the top links had a maximum width. Since now the body
has that maximum width, we no longer need the row element.
In the other layouts I guess the row elements were added because there
were float elements inside them. We can use a flexbox layout instead and
these elements are no longer necessary. This also makes the layout more
robust when there isn't enough space on one line for both the language
selector and the external links.
Note we're using `flex-grow: 1` to make one element appear on the left
of the screen and the other one on the right. It would be easier to use
`justify-content: space-between`. However, there's a bug in Internet
Explorer and old versions of Firefox; they include the
absolutely-positioned `::before` element we use to set the full width
background when calculating where to position the elements. The bug was
fixed in Firefox 52 (released in 2017).
These element had no columns inside and the row classes had only been
added to give them a maximum width. That's no longer necessary since now
the body has that maximum width.
Note that in order to simplify the component tests (which for some
reason seem to be whitespace-sensitive), we have to omit whitespace
characters inside the `<option>` tags.
Also note we're simplifying the test with a missing language name; since
a component test doesn't involve a whole request, we don't need a
complex setup (I'm not sure we even need it in system tests).
The `<optgroup>` doesn't make much sense if all options are inside one
group. And the information provided was redundant: when using a select
field having "Language" as a label, it's obvious that the options are
the available languages.
Now that, since now the `<select>` field is smaller, we need to add an
extra padding so the icon doesn't overlap the text.
The language attribute is present in all layouts since commit 025923ac4,
so there's no need to use the language selector locale. Besides, it
wouldn't work if there's only one locale and the language selector isn't
shown.
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.
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.
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.
As mentioned in the previous commits, a `<select>` field which submits
its form on change causes many accessibility and usability issues, so
we're replacing it with the order links we use everywhere else.
Since the links "Id" and "Title" by themselves don't have enough
information to let users know they're used to sort by ID or title, we
have to update them somehow. We could add a "Sort by:" prefix before the
list of links (and associate it with the `aria-labelledby` attribute);
however, we don't do this anywhere else and might look weird depending
on the screen size.
So we're simply adding "Sort by" before each link.
Now that we don't use the `wide_order_selector` partial anymore, we can
remove it alongside the styles for the `select-order` class.
A `<select>` tag here might make more sense than in other similar places
since there are 5 options to choose among, and using links might take
too much screen space.
However, as mentioned in the previous commits, `<select>` tags which
automatically submit a form have many accessibility and usability
issues.
An alternative would be to create a dropdown menu with a button and a
list of links (similar to what Foundation does). I'm keeping the links
for simplicity and because the interface looks a bit more consistent
with the rest of the sections. Before these changes, we had a heading,
then a `<select>` field to choose the filter, and then a button to print
the page. We never use a similar interface, and some people might think
the "Print" button is related to the same form as the `<select>` field.
Now that we don't use the `order_selector` partial anywhere anymore, we
can remove it.
We had five almost-identical views. Now we've removed most of the
duplication, although the tables are still similar. We might refactor
them in the future.
In keys like `hide_debates`, the suffix part is redundant when that key
is part of an absoulte key starting with `moderation.debates`.
This change will make it easier to remove duplication in moderation
views.
It was a bit frustrating to click on one of the order elements or the
link to the next page and having to scroll down again until reaching the
comments.
We use order links in many places in the web. However, in the comments
section and the list of community topics, we were displaying a
`<select>` element, and changing the location when users select an
option.
This has several disadvantages.
First, and most important, it's terrible for keyboard users. `<select>`
fields allow using the arrow keys to navigate through their options, and
typing a letter will select the first option starting with that letter.
This will trigger the "change" event and so users will navigate through
a new page while they were probably just checking the available options
[1]. For these reasons, WCAG Success Criterion 3.2.2 [2] states:
> Changing the setting of any user interface component does not
> automatically cause a change of context unless the user has been
> advised of the behavior before using the component.
Second, the form didn't have a submit button. This might confuse screen
reader users, who might not know how that form is supposed to be
submitted.
Finally, dropdowns have usability issues of their own [3], particularly
on mobile phones [4]
The easiest solution is to use the same links we generally use to allow
users select an order, so using them here we make the user experience
more consistent. They offer one disadvantage, though; on small screens
and certain languages, these links might take too much space and not
look that great. This issue affects pretty much every place where we use
order or filter links, so we might revisit it in the future.
Note we're moving the links to order comments after the form to add a
new comment. In my opinion, having an element such as a form to add a
new comment between the element to select the desired order of the
comments and the comments themselves is a bit confusing.
[1] https://webaim.org/techniques/forms/controls#javascript
[2] https://www.w3.org/WAI/WCAG21/Understanding/on-input.html
[3] https://www.youtube.com/watch?v=CUkMCQR4TpY
[4] https://www.lukew.com/ff/entry.asp?1950
Just like we do in debates, proposals, ... We could argue whether it's
better to have the form before or after the list of comments, but at the
very least we should have some sort of consistency.
"Is it related content? Yes (link) No (link)".
After reading that, you probably haven't decided whether to click the
"Yes" link or the "No" link or neither of them. You probably have to
read the content it's related to, and then go back to these links.
That's the reason we style them so they're on the right of the screen on
languages which are read from left to right, so first we read the
content and then we read the links to mark it as related or unrelated.
So it makes sense to put these links after the content they refer to.
This way users with small screens as well as screen reader users will
also see/hear these links after they get the proper context. It will
also be more intuitive for keyboard users, who saw the focus on the
links before focusing on the title of the related content, when they
probably expected the opposite.
Since we're now using a flexbox layout instead of a right float, this
also means the content will automatically be shown on the left when
switching the content direction to "right to left".
We were only showing these actions to users with small screens and to
mouse users on hover. Keyboard users or users with a touch screen of a
medium or large size could never find out the actions were there.
It didn't have a `for` attribute and so it wasn't correctly associated
with its input. That means clicking on / touching the label didn't have
the effect of focusing on the field, and screen readers wouldn't
announce the label.
The button was announced as expanded when the form was hidden and as
collapsed when the form was shown.
This is because Foundation sets the expanded attribute based on whether
the class to toggle already exists. Since initially the form had the
"hide" class and the button toggled that class, Foundation checked that
the class was already present and so set the button as expanded.
So we're changing the toggler class for a class we don't use at all,
just so Foundation initiall sets `aria-expanded=false` and then changes
it to `aria-expanded=true` after the button is clicked. Then we're
ignoring this class completely and are styling this form with CSS
instead.
We could also use a toggler class like "visible" and write something
like:
```
.add-related-content + form:not(.visible) {
display: none;
}
```
However, using ARIA attributes is more robust as it guarantees the
styles will always be in sync with what screen reader users experience.
And we could also remove all the Foundation toggler functionality and
use our own JavaScript to handle the button state. We might do so in the
future.
This way the relationship between the two elements is more obvious. And
since now the button and the form are siblings, it's easier to find one
based on the other using CSS or JavaScript.
We were using a placeholder to indicate content which should be part of
a label.
It might be better to actually use "Link address" as a label instead of
"URL". I'm using "URL" because it's used in other places in the admin
section.
We were using a paragraph before the field, and then a field with no
label and a redundant placeholder. This causes accessibility issues for
screen reader users, who will not hear the label being announced when
entering the field, and to users who click on the label expecting it to
automatically focus on its related field (which is the standard browser
behavior).
Using placeholders having similar (or identical) text as already present
as a label has a few issues.
First, it's a distraction. Reading the same information twice is
useless, requires an extra effort, and might even frustrate users.
Second, if users start typing before reading the placeholder and see it
disappear, they might think they're missing relevant information,
delete what they typed, and read the placeholder. That will get them
nowhere.
Finally, we display placeholders using a text offering very low contrast
against the background, so users don't think the placeholder is an
actual value entered in the field. Using such low contrast makes the
text hard to read, particularly for users with visual impairments.
So we're removing these placeholders.
This commit only deals with placeholder texts with similar (or
identical) texts as the label text. There might be other places where we
should replace placeholder texts with labels, but that's a different
topic.
