This way it's easier to refactor it.
Note we're using `with_request_url` in the tests because the component
renders the locale switcher, which needs a URL in order to work. This
doesn't affect whether we're in the management section or not.
This way it will be possible to write CSS and JavaScript code that will
only apply to specific tenants.
Note that CSS customization is still limited because it isn't possible
to use different SCSS variables per tenant.
We forgot to do so in commit d827768c0. In order to avoid the same
mistake in the future, we're extracting a method to get these
attributes. We're also adding tests, since we didn't have any tests to
check that the `dir` attribute was properly set.
As mentioned in commit 5214d89c8, using the `change` event of a `select`
field to automatically change location is really annoying for keyboard
users, since the event will trigger when pressing the down key to
navigate through the options or when typing a key to start searching for
an option. This might cause a lot of frustration.
Most multilanguage CONSUL sites enable between 2 and 4 languages. In
these cases, it's easier to just display the list of languages to
simplify the selection.
This way in this situation we also make it clear which languages are
available. If we use a `<select>` tag, users will have to open it in
order to check whether the site is available in their preferred
language.
This is also useful when the current language uses characters users
don't recognize; users will recognize their own language in the list of
available languages, while it might be harder to recognize the language
selector allows them to switch to a different language.
In this case, we're also hiding the label because a list of links with
language names is usually self explanatory for sighted users. We're
still providing it for screen reader users so they immediately know the
list allows them to change the language and if they don't need to do so
they can quickly skip it.
I'm not sure screen readers recognize this attribute inside `<option>`
tags, but if they do, it'll probably be helpful. And if they don't, no
harm will be done.
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).
We've had an accessibility error reported by the Spanish "Portal
Administración electrónica" (PAe). While I can't find any accessibility
rule saying empty lists should be avoided, it looks like some screen
readers report finding lists with 0 items, which is annoying.
We've had an accessibility error reported by the Spanish "Portal
Administración electrónica" (PAe). While I can't find any accessibility
rule saying empty lists should be avoided, it looks like some screen
readers report finding lists with 0 items, which is annoying.
We could also do it with CSS using `ul:empty { display: none}`. However,
at the time of writing no browser supports this rule when the tag
contains whitespace.
We were displaying the total number of notifications with a message "You
have N unread notifications", but were using the total number of
notifications instead of the unread ones.
Other than simplifying the view, we can write tests using `click_link`,
which makes the tests more robust. Clicking the `.icon-notification`
element was causing some tests to fail when defining a window height of
750 pixels in the `admin_budgets` branch.
