While people using screen readers already have keyboard shortcuts to
jump to the <main> tag, there are people who navigate the page with the
keyboard using just the tab key, and for them, this link provides a way
to save time and start reading the main content instead of having to
manually go through all the navigation links every time a new page is
loaded.
Note that we had to add an additional `width: 0` rule because
Foundation's `element-invisible` would apply `1px` and the test checking
for `visible: :hidden` would faile.
As mentioned in earlier commits, opening external links in a new
tab/window results in usability and accessibility issues.
Since these links are usually at the top or bottom of the page and
contain icons of well-known sites, IMHO there's no need to even notify
people that these are external links.
Since we're no longer using the `shared.target_blank` translation inside
a sentence, we can remove the space and parenthesis in the translations.
In order to comply with the security measure for the
ENS: "[op.acc.5.r5.2] The user shall be informed of
the last access made with his identity".
We have added a new secret to display the last
access made to the user on the "My account" page.
Internet Explorer 8 was released in 2009 and people using it already
know that most web pages look broken on it, so we don't need to warn
them.
Removing it makes our application layout file much easier to read and
modify.
The `reload` method added to max_votes validation is needed because the
author gets here with some changes because of the around_action
`switch_locale`, which adds some changes to the current user record and
therefore, the lock method raises an exception when trying to lock it
requiring us to save or discard those record changes.
We need to update a couple of tests because a poll is created in the
tests with a timestamp that includes nanoseconds and in the form to edit
the time of the poll the nanoseconds are not sent, meaning it was
detected as a change.
We had the same texts four times, with slight variations in the case of
the management section.
We're unifying them under the "verification" i18n namespace, since the
texts are about actions which can be done depending on whether users are
verified or not.
Note the names of the i18n keys aren't very consistent, since we use
"debates" in plural but "proposal" in singular. We're leaving it like
this so existing translations aren't affected.
We were saying that actions marked with an asterisk were only possible
when users were verified. However, there were no actions marked with an
asterisk; instead, we didn't show these actions to non-verified users.
Besides, the concept of Census doesn't exist in many CONSUL
installations, where verification is done through other means, so the
text saying that only users on Census could do certain things wasn't
correct in these cases.
Due to that, we're removing the asterisk in the Spanish version as well.
We're also removing the asterisk in the default welcome pages, since
we're already saying which action can't be done until the account is
verified.
In the case of the residence verification page, we had asterisks but we
didn't explain what the asterisk stood for, so we're also removing it.
We were using very similar code for proposals, debates and investments,
so we might as well share the code between them.
Note we're using the `proposals.index.search_results` key even for
debates and investments. This will still work because the translations
shared the same text, but IMHO we should rename the key to something
like `shared.search_results_summary`. We aren't doing so because we'd
lose all the existing translations.
Since we're going to remove Paperclip and Active Storage doesn't provide
any validations, we have to either write our own validation rules or use
a different gem.
We're using the file_validators gem instead of the
`active_storage_validations` gem because the latter doesn't support
proc/lambda objects in size and content type definitions. We need to use
them because in our case these values depend on settings stored in the
database.
We were using the same logic six times regarding when we should show a
"participation not allowed" message. Since we're going to change the
current behavior, we're unifying the logic in one place so the changes
will be easier.
Hovering over the votes showed a "participation not allowed" message
which was annoying when scrolling with the browser or simply moving the
mouse around the page. Furthermore, it hid the information about the
number of votes, links to show/collapse replies, ...
We're planning to change the behavior of all the "participation not
allowed" messages in order to show them on click instead of showing them
on hover (just like it's done on touchscreens). In the case of comments,
supports, however, there's very limited space in the part showing the
number of supports for comments, so adding this message without breaking
the layout is challenging.
So, for now, we're simply redirecting unauthenticated users to the login
page. If find an easy way to implement a better user interface in the
future to display the "participation not allowed" message, we might
change this behaviour.
This way blind screen reader users will know which proposal they're
supporting. In a list of proposals, context might not be clear when a
link saying "Support" or "Support this proposal" is announced, but a
link saying "Support Create a monthly transport ticket" is less
ambiguous.
Just like we did with investments in commit de436e33a, we're keeping the
title attribute because when visiting a proposal page, the connection
between the "Support" link and the proposal is not as clear as it is in
the proposals index page, so it might not be clear what you're
supporting.
The `legislation_proposals#index` action was never used because it used
the same URL as `legislation_processes#proposals`.
In commit 702bfec24 we removed the view, but we forgot to remove the
controller action, the route, and some partials which were rendered from
the index view.
Originally there was a link pointing to the FAQ page but it was removed
in commit e14b7b67fb because by default the FAQ page in CONSUL only
contains a placeholder text.
We aren't sure where this link should point:
* FAQ page, only if the FAQ page is published
* Help page, only when the help feature is enabled
* CONSUL technical documentation page
So, for now, we're choosing the easiest solution which is removing the
text completely.
Usability tests showed some users were struggling when seeing the word
"Required" as a legend (it's actually styled as a title), since this
isn't a common pattern when filling in forms. They were expecting
something like "Fields with * are required", and so the "Required" text
alone made them feel the sentence wasn't complete.
We could also add an "*" to required fields in addition to the
"Required" text. In this case, however, some users wondered what the
asterisk was about: "It can't mean 'required' because they've already
said these fields are required".
We'll probably have to revisit required and optional fields again. For
now, we're just doing a small improvement.
When users see a label saying "With the text" and an input field, they
don't usually need a placeholder saying "Write the text". On the
contrary, this text adds noise and is hard to read due to the low
contrast between the color of the placeholder and the color of the
field, making the text an unnecessary distraction.
User testing has shown this filter isn't really useful and sometimes
makes users wonder what it's about. This is particularly true in CONSUL
installations which don't change the default values (most of them),
since users will see a filter with options like "Official position 1".
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.
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.
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 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
It looks like this bug was introduced in commit 7ca55c4. Before that
commit, a message saying "You added a new related content" was shown,
but (as expected) the related content wasn't added twice.
We now check this case and add a slightly clearer message.
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.
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.
We were using a custom icon because in the past social-share-button
didn't have support for whatsapp. But now that it does, we can remove
our custom icon.
Note we're using the `_app` suffix because that's the name of the icon
meant for mobile devices.
