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.
We were displaying documents in five places, and in five different ways.
Sometimes with the metadata in parenthesis after the title, sometimes
with the metadata below the title, sometimes without metadata, sometimes
with an icon in front of the document, and sometimes with a separate
link to download the file.
So we're now displaying the same thing everywhere. Not sure whether this
is the best solution, but at least it's consistent.
We aren't unifying the way we display a list of documents, though, since
different sections look pretty different and I'm not sure whether the
same style would look well everywhere.
Note that we're renaming the `document` HTML class in the documents
table to `document-row` so the styles for the `document` class don't
apply here.
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
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.
We added the feature to undo a vote and made it obvious for people using
screen readers using the `aria-pressed` attribute. However, for sighted
people, the only way to know a button can be unpressed is to try to
press it again and see what happens.
The most obvious way to indicate it would be to add a text indicating
that you can undo your vote. However, that'd require changing the design
quite a bit.
So, after trying a few techniques, we're using a classic approach
browsers have used by default for years: using an inset border for
pressed buttons and an outset border for unpressed ones. It might now be
enough, though; we haven't done usability tests to confirm this point.
Since icons to like/unlike comments don't have a border, I'm not sure
what to do in this case; the icons are small and that makes it hard to
style them in a distinct way. So for now we're not changing these icons.
Since we were styling pressed buttons the same way as buttons on hover,
a person hovering on the button and then clicking it wouldn't notice
that the buttons had been pressed unless they noticed that the number
and percentages of votes had changes. They wouldn't notice the changes
when unpressing the buttons either, since, after clicking the button,
the cursor would still be over it, and so the hover styles would apply.
Furthermore, it was hard for mouse users to realize that a button could
be unpressed, since the style of pressed buttons didn't change on hover.
So we're now changing the icons on hover without changing the
background. This way all four states (unpressed, unpressed on hover,
pressed, pressed on hover) are styled in a different way.
The colors we were using (gray for unpressed buttons and green or red
for pressed buttons) didn't contrast well against a white background, so
we're now using darker colors.
However, with darker colors, using solid icons for the unpressed buttons
makes it harder to differentiate when a button is pressed and when it
isn't, particularly for color-blind people.
So we're now using regular icons for the unpressed buttons and solid
icons for the pressed ones.
We were using the same selectors three times. Since we're going to
change that part of the code, we're simplifying it so we don't have to
do the same changes three times.
Other packages depend on jQuery, so that's why these are the first one
we move from the Gemfile to the package.json file.
This way we can also test whether dependabot correctly opens pull
requests to update Node packages.
I've tried several configuration options for the asset pipeline in order
to be able to include images referenced in jQuery UI CSS files. So far,
adding the `node_modules/jquery-ui/themes/base` folder to the assets
paths is the only way I've found to make it work. Hopefully we can find
a better solution in the future so we don't have to study the internals
of every Node package in order to integrate it with the assets pipeline.
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.
We were displaying the alt text using the same color as the background
color, which made it impossible to read it when the logo didn't load
(for whatever reason).
Using the same color as the text, like done in the admin section, solves
the issue.
The color we were using didn't have enough contrast against a white
background, which made it harder to read texts like "Remove map marker"
or "Erase my account".
Since the new color is almost identical to the color we were using on
hover and for the border, we're changing the color on hover as well,
while IMHO it's no longer necessary to use a different color for the
border.
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/
In some cases, like SDG icons and the proposals map, the image was
bigger than the link containing it, resulting in a funny-looking outline
on focus.
For reasons I don't understand, using `&:active,&:focus:active` didn't
compile to the CSS I was expecting, so I'm repeating the same code for
these two separate cases.
The outline was invisible when we had the link containing block
elements, and I didn't manage to fix it, so the easiest solution is to
use an inline link and style the card with CSS.
This way it's going to be easier to style the link on focus, since
styles like `box-shadow` weren't working properly when we had an inline
link with block elements inside, and adding the `display: inline-block`
element to the link didn't play well with the layout we were using for
the recommendations.
We're also fixing the focus outline on recommendations, which didn't
look properly because of the border added with:
```
.recommended-index {
// (...)
@include full-width-border(top, 1px solid #fafafa);
}
```
The border was on top of the outline, breaking it. Increasing the
`z-index` of the element containing the outline solves the issue.
In a similar way, we're making sure the button to hide recommendations
stays visible so it's easier to click it.
In order to reduce the code used to add styles to the buttons,
we removed the classes that had been added and handled it with
the new aria-pressed attribute
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.
It was obvious which project the comment was about. Also, no point
having a TODO referencing what to do after upgrading to Rails 5.1, since
we did it years ago.
* Add Tables option to Redcarpet in Legislation draft
* Allow table tags in Admin Legislation Sanitizer
* Add Test to render markdown tables in Legislation drafts
* Add Test for Admin Legislation Sanitizer
We include test for image, table and h1 to h6 tags and additional tests to strengthen the allowed and disallowed parameters
* Add Table from markdown test in System and Factories
* Add test to render tables for admin user
* Remove comment line about Redcarpet options
* Edit custom css for legislation draft table to make it responsive
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.
Zooming with the mousewheel is useful when you want to use it, but
annoying when you don't want to.
Here we're taking an intermediary approach: by default, the mousewheel
isn't active, but it will be active after focusing on the map, so it can
be used both to scroll and to zoom.
This behavior presents usability issues, though, since we aren't making
users aware of the way the mousewheel works, and even if they were
aware, it could be confusing anyway. However, I currently think it's
better than always enabling or always disabling the mousewheel (might
change my mind, though).
Note that the "focus" event is only used on the map, so if we click on a
marker or navigate to a marker with the keyboard without focusing on the
map first, the mousewheel isn't enabled. The same would happen if we
used the "click" event.
We might use the Leaflet.GestureHandling plugin in the future to deal
with this issue and the scroll on touch screens.
By using the bindPopup function instead of the click event
popups work when using the keyboard.
Note that now we are loading all the map markers in the first
request in a single query to the database (needed when there
is a lot or markers to show). Because of that we removed the
AJAX endpoint.
Note that in the budgets wizard test we now create district with no
associated geozone, so the text "all city" will appear in the districts
table too, meaning we can't use `within "section", text: "All city" do`
anymore since it would result in an ambiguous match.
Co-Authored-By: Julian Herrero <microweb10@gmail.com>
Co-Authored-By: Javi Martín <javim@elretirao.net>
