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.
Nowadays there are many users with a screen of 1920px (or higher) width
but who don't change their font-size preferences and keep them at 16px,
which is the default in most browsers.
On pages which use the whole window width, that results in unreasonably
long lines which are very hard to read. That's the main reason why many
sites (including CONSUL) use rules like `max-width: 75rem` for the body
or other elements.
However, on extra large screens this causes the content to be in the
middle of the screen while most of the screen is empty, and the text
might also be too small for that resolution, making it harder to read.
There are a few approaches to solve this problem.
Using just viewport units like `font-size: calc(4vw + 4vh + 2vmin);` is
indeed responsive, but it's got an important flaw: it ignores user
preferences, and so the font size will be the same for users who prefer
a 16px size and for users who prefer a 32px size.
Using `calc(1em + 0.2vw)` or similar might make the text too big on
small screens.
Finally, using `max(1em, 1vw)` would work in a similar way to what we're
doing, but zooming in and out would only work when the viewport width is
less than 100em (at that moment, 1em == 1vw).
So we're taking an approach where zooming in and out always works at
least to a certain degree (due to the 0.25em part) and the font size is
increased gradually when we reach the point where the viewport width is
bigger than 100em. We're using 0.25em since it will be exactly 4px with
the default browser configuration, and so calculations are easier than
with (for example) 0.3em.
Disclaimer: I've tested this feature on several devices with different
screen sizes and resolutions, but I must admit there might be cases I'm
unaware of where there are side effects for certain combinations of
screen size/resolution/dpi. In general, though, the side effects should
be similar to what happens when users increase the font size in their
browser's preferences.
Note we're using `Max` instead of `max` because Sass can't handle the
CSS `max` function, as mentioned in commit cdfa23fc6.
When the "Or fill the following form" text was translated to another
language or customized by administrators, the text could span over two
lines. Since the element had a fixed height, it could overlap with the
text below it.
So now we're using an element with a relative position to achieve the
same effect (have the contents of the elements on top of its border).
Using pixels to define font sizes has an important problem: it ignores
user settings. No matter whether users set their font size to 16px (the
default font size in most browsers), to 18px (like I do) or to 32 px
(like users with huge screens or with a visual disability); the size
will not change.
Even if most browsers can zoom to somehow overcome this issue, it's
still annoying. And, in our case, we use relative units most of the time
but absolute units in some places. This leads to situations where some
of the text gets larger when users increase their font size while some
of the text remains the same. Sometimes this results in titles having a
smaller size than regular text below it.
The solution is using relative units everywhere. Quoting the Web
Accessibility Initiative guide for styles [1]:
> The user needs to be able to resize the text to 200% of its size
> anywhere on the page, without the text being cut off or overlapping
> other text. The font size should be defined in relative units, such as
> percentages, em or rem. It is not possible to zoom text set in pixels
> independently from the rest of the page in some browsers.
[1] https://www.w3.org/WAI/tutorials/page-structure/styling/
Using links combined with JavaScript to generate POST requests to the
browser has a few issues.
An obvious one is that it doesn't work for users without JavaScript
enabled (which lately I've noticed are more common than I thought, even
though I've been one of them for years). These users will reach a 404
page.
Since CONSUL isn't currently designed to work without JavaScript
enabled, let's ignore this one for now.
A not so obvious issue is screen reader users might expect the link to
take them somewhere instead of performing an action (in this case,
sending a form to the server).
There might be more issues I'm unaware of. Quoting DHH [1]:
"Turning ahrefs into POSTs is a bit of an anti-pattern, especially for
a11y reasons. Better to use button_to with a styling."
So we're using a button instead. This way we can also simplify the code
and make the button disabled for unidentified users, which automatically
makes it impossible to focus it using the keyboard.
A possible disadvantage of using `button_to` is it will create a form
tag which will be announced to screen readers as a form landmark. I've
tested it with my screen reader and everything worked fine for me, but
some screen reader users might interact with these forms in a different
way and find it confusing, particularly in the case where the button is
disabled.
With this change, we're only changing links for buttons in one place.
There are other places where we should do similar changes.
[1] See issue 33 in https://github.com/hotwired/turbo-rails/
The color we used offered a contrast of 3.94 against the background. The
minimum requirement for AA level is a contrast of 4.5, and we usually
aim for a contrast of 5 at least.
So we're making the text slightly darker so it's easier to read.
Note one of the tests dealing with random results is a bit flaky; since
it's a permutation selecting 7 objects out of 12, it will fail about
once every 4 million times. We think this is acceptable.
Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
Note we're using an extra `<span>` element but we could use a CSS grid
layout instead. We're not using it because browser compatibility is only
94.56% at the time of writing.
- Allow to define a link (text and url) on budget form for render on the budget
header.
- Improve styles
Co-authored-by: Senén Rodero Rodríguez <senenrodero@gmail.com>
So now there's no need to edit each phase individually to enable/disable
them.
We aren't doing the same thing in the form to edit a budget because we
aren't sure about possible usability issues. On one hand, in some tables
we automatically update records when we mark a checkbox, so users might
expect that. On the other hand, having a checkbox in the middle of a
form which updates the database automatically is counter-intuitive,
particularly when right below that table there are other checkboxes
which don't update the database until the form is submitted.
So, either way, chances are users would think they've updated the phases
(or kept them intact) while the opposite would be true.
In the form within the wizard to create a budget that problem isn't that
important because there aren't any other fields in the form and it's
pretty intuitive that what users do will have no effect until they press
the "Finish" button.
Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
Note we're keeping this section's original design (which had one button
to add a new group which after being pressed was replaced by a button to
cancel) but we aren't using Foundation's `data-toggle` because there
were a couple of usability and accessibility issues.
First, using `data-toggle` multiple times and applying it to multiple
elements led to the "cancel" button not being available after submitting
a form with errors. Fixing it made the code more complicated.
Second, the "Add new group" button always had the `aria-expanded`
attribute set to "true", so my screen reader was announcing the button
as expanded even when it wasn't. I didn't manage to fix it using
`data-toggle`.
Finally, after pressing either the "Add new group" and "Cancel" buttons,
the keyboard focus was lost since the elements disappeared.
So we're simplifying the HTML and adding some custom JavaScript to be
able to handle the focus and manually setting the `aria-expanded`
attribute.
Co-Authored-By: Javi Martín <javim@elretirao.net>
Co-Authored-By: Julian Herrero <microweb10@gmail.com>
Using the placeholder selector, we weren't overwriting the rules in the
mixin called with `@include` in some cases because in the generated CSS
the placeholder selector appeared before the code generated by the calls
to `@include`.
This way we make it more obvious that it's clickable and, since adding a
border requires adding padding, we increase the touch area, making it
easier to use and more accessible for users with motor disabilities.
Since now the button looks like a button, we don't need the pointer
cursor Foundation adds to hamburger icons and can use the default cursor
browsers provide for buttons.
Some users might not be able to touch the icon due to a motor
disability. Other users might think the "Menu" text is part of the
button and try to touch it instead.
Making the "Menu" text part of the button makes it easier to show/hide
this menu. Besides, it lets screen reader users with a small screen hear
the word "Menu" associated to the button.
We could simplify the HTML a bit more but Foundation's `hamburger` mixin
uses the `::after` element with `position: absolute`, so we can't apply
it directly to the button without making the CSS more complex.
Using `currentcolor` and `color: inherit` is IMHO more expressive (we're
saying we want to use the same color as the text) and makes it easier to
customize these colors in other CONSUL installations. We also remove
duplication as we can use the same styles for both the admin and the
public layouts.
So other institutions customizing CONSUL can organize their custom code
as they wish to.
We're also updating the comments in the `custom.scss` file, since it was
referencing files which no longer exist.
On small screens, sometimes the bottom of the footer didn't have the
footer's background color.
I'm not sure why the `min-height` rule affects this outcome. However,
since this rule usually results in footer with quite a bit of empty
space at the bottom, we can simpliy remove the rule and use padding to
guarantee there's a bit of space between the text in the footer and the
bottom of the screen.
Before commit 28caabecd, it was clear which budgets were in draft mode
because their phase was "drafting".
Now the phase isn't "drafting" anymore, so we have to make it clear
somehow that the budget is a draft.
I'm using styles similar to the ones we added in commit 2f636eaf7 for
completed budgets but at the same time making them slightly different so
it's easy to differenciate completed and drafting budgets.
Using `<a>` tags with no `href` means these elements cannot be activated
by keyboard users, so we're replacing them with buttons.
In the future we probably want to add more consistency so all toggle
buttons use the same code. We might also add styles depending on the
`aria-expanded` property.
Note we're absolutely positioning the link instead of the icon; that way
keyboard users will be able to focus on the icon. Until now, users would
focus on an empty link.
For the same reason, we couldn't use `click_link` with Capybara, since
it would fail to click an empty link. Now we can.
Co-authored-by: Javi Martín <javim@elretirao.net>
Since we were defining the selection to have the same text color and
background color as the element they were in, it resulted in the
selection being invisible.
It wasn't that noticeable because we were using this color combination
mainly in links and buttons, and selecting their text is not as common.
But we plan to use the `$brand` color on budget headers as well, and
this issue is more obvious there.
Browsers like Chrome weren't that affected because they automatically
make the selection semi-transparent and so the selected text still had a
slightly different color. In order to prevent this effect when the
selection is white, we're using a 0.99 opacity (in this case Chrome
ignores numbers higher that 0.998).
