Note that adding the labels broke the layout because the button was no
longer aligned with the fields, so we're now using a flex layout.
Since we're using labels, we no longer need a placeholder (which wasn't
very informative, by the way) in the text field.
The `clear` class isn't needed since commit c9f31b8e1, when we moved
this button above the regular search fields.
We're also moving the `float` property to the CSS file.
The text for the unfeasible checkbox wasn't correctly defined as a
label, while the fields to search investments and select the heading
weren't intuitive since their purpose wasn't obvious.
With a 50% width on medium and large screens, depending on the size of
the text and the size of the screen, the label could unnecessarily use
two rows, looking broken.
Since the main stats index loads this JavaScript using
`"data-turbolinks-track" => "reload"`, going from the stats index to a
section that doesn't include this JavaScript did the strange effect
Turbolinks does in these situations: it first loaded the page using an
AJAX request and, after getting the contents of the page, it reloaded it
in order to apply the changes in the included JavaScript.
This behavior was a bit confusing, particularly when browsing to a
section of the admin stats, clicking the browser's back button to go
back to the stats index, the going to another section, ...
One of the admin stats tests was failing sometimes with this message:
```
1) Stats Budget investments Supporting phase Number of users and
supports in investment projects
Failure/Error: raise ex, cause: cause
Selenium::WebDriver::Error::UnknownError:
unknown error: unhandled inspector error:
{"code":-32000,"message":"Node with given id does not belong to the document"}
(Session info: chrome=129.0.6668.89)
```
This was probably caused by the mentioned Turbolinks behavior that loads
the page twice. It's possible that Selenium was somehow checking the
node related to the first request when the second request had finished.
Avoiding that double request solves the issue.
This way it'll be easier for people using screen readers to know which
element the checkbox is related to.
Note that we're using the `aria-label` attribute because it makes
testing with Capybara easier than using the `aria-labelledby` attribute.
The only exception are the comments, since comments don't have a title
and there isn't a proper label for them. In this case, we're using the
title of the associated commentable as the label; we might change it in
the future since there might be many comments for the same commentable.
We were rendering one label and many textarea fields for that label.
This meant that, when switching to a different language, the label
wasn't correctly associated with the textarea.
So we're now rendering one label for each textarea. We could use
`aria-label` or `aria-labelledby` instead, but using a label offers some
advantages like the fact that clicking on the label makes the textarea
take the focus.
The absence of labels in these controls made them hard to use,
particularly for people who use screen readers.
Note we're removing the "Choose language" prompt, since we always
automatically choose a language and not choosing a language doesn't
really make sense. The only scenario where the prompt was used took
place when all languages had been removed but, in that case, the "Choose
language" prompt was misleading because there were no languages to
choose from.
We were using `check "Valuation finished"` everywhere except here.
This way it's easier to realize, while reading the test, that we're
interacting with a checkbox and not a link or a button.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Since we're adding styles for this button, we're also adding the
`font-size` property instead of using the `small` class. We'll deal with
the `float-right` property in the next commit.
This way it'll be easier for people using screen readers to know which
link/button they're about to click.
Note that, at least for now, we aren't reusing the code en
`Admin::ActionComponent`. We might do so in the future if we implement
similar code in more parts of the public area.
Note that, since the button now generates a `form` tag, we need to
adjust the styles of this section.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Note we're simplifying the `table .button` margin rules because the
`.button` class already defines `0` for all its margins except the
bottom margin. Otherwise, the margins defined by the `flex-with-gap`
mixin would be overwritten by the margins defined in the `table .button`
class.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commit,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
While testing for accessibility issues (in a development branch), we're
removing Turbolinks and monkey-patching the behavior of the `click_link`
method to check the page for accessibility issues after each request.
However, we were getting false positives when clicking links that act
like buttons.
So, for the reasons mentioned in commit 5311daadf, we're replacing the
link to delete a document with a button.
We forgot to do so in commit f0ab7bcfc. We're still leaving one system
spec to test that these images are rendered when browsing the site.
We're also changing the existing component tests to check the `alt`
attribute, just like the remaining system test does.
Just like we did in commits like f2e32b44b, a8537f7e1 and be9fc2265,
we're replacing a buggy JavaScript solution with one using just CSS.
Besides, we've had a failure in our test suite caused by an image not
being displayed on the page, with the message:
```
Failures:
1) Executions Images renders last milestone's image if investment has multiple milestones
with images associated
Failure/Error: expect(page).to have_css("img[alt='Second image']")
expected to find visible css "img[alt='Second image']" but there were no matches.
Also found "", which matched the selector but not all filters.
# ./spec/system/budgets/executions_spec.rb:135:in `block (3 levels) in <top (required)>'
```
The text "matched the selector but not all filters" means that the
element was present on the page but wasn't visible. One possible cause
is that the equalizer was adjusting the height of the element containing
the image before the image was loaded.
Note that, after these changes, all investments on the same row will
have the same height but, unlike with Foundation's equalizer,
investments on different rows might have different heights.
Note that we're changing the component so it uses `polymorphic_path`;
that way we don't have to pass the `@budget` variable to the component.
We could also use `budget_investment_path investment.budget, investment`
instead.
