Forem: Carlos Espada

HTML tags | hgroup

Carlos Espada — Thu, 16 May 2024 07:39:33 +0000

It is used to group a heading with some type of related secondary content, such as a subheading or tagline. This secondary content will go inside a <p>.

Therefore, within a <hgroup> we can only find a <p> preceding a single header from <h1> to <h6> and another <p> below. It is not allowed to have more than one heading.

It has an implicit ARIA role generic, so it has no impact on the page outline. This impact is given by the header it contains.

Type: block
Self-closing: No
Semantic value: No

Definition and example | Support

HTML tags | search

Carlos Espada — Wed, 22 Nov 2023 11:47:37 +0000

It is used to group the elements (normally form controls) that have the capacity to carry out a search or filtering, whether related to the document, the website/webapp or the entire Internet.

It should not be used to present search results, but rather these should go in the <main> of the page.

What does have to go inside <search> are the search suggestions and links that are part of the quick search functionality that is usually used in many search engines or filters.

It has an implicit ARIA role search, thus eliminating the need to add role="search" to the <form>. For practical purposes, there is no difference between using one or the other, but <search> respects the ARIA principle of not using ARIA roles when there is a native element that provides the same functionality.

Type: block
Self-closing: No
Semantic value: Yes

Definition and example | Support

A11y: notify user after submitting a form

Carlos Espada — Fri, 28 Jan 2022 10:10:23 +0000

When the user fills out a form, they must be informed of the result of their submission, whether it is correct or contains errors. To do this, several steps must be followed, which may vary depending on whether the page is reloaded or if the submit is done asynchronously using JavaScript.

Let's take as an example a very simple contact form, with a name, email and message.

<form>
  <div>
    <label for="name">Name</label>
    <input
      id="name"
      name="name"
      type="text"
      autocomplete="name"
      required
    />
  </div>
  <div>
    <label for="email">E-mail</label><br>
    <input
      id="email"
      name="email"
      type="email"
      autocomplete="email"
      required
    />
  </div>
  <div>
    <label for="message">Message</label><br>
    <textarea
      id="message"
      name="message" 
      rows="5"
      cols="70"
      required
    ></textarea>
  </div>
  <button>Send</button>
</form>

In both situations, classic sending by reloading the page or made it asynchronously, the steps are these:

Create an area at the beginning of the form that contains a header and a list of errors, if any.
The header must contain the message reporting the result of the shipment, either correct ("Your message has been sent") or erroneous ("There are 3 errors in your form, please check it").
If there are errors, just below the header we will put *a list reporting briefly and descriptively of each of the errors.
Each item in the list will link to the corresponding form field.
Each item in the list will serve as a description of the error using the aria-describedby attribute.

So, in our example, if we tried to submit the form with all the fields empty, we would get this:

<form>
  <div>
    <h3>There are 3 errors in your form, please check it</h3>
    <ul>
      <li>
        <a id="error-name" href="#name">The name field is empty. It's a required field and must be filled in.</a>
      </li>
      <li>
        <a id="error-email" href="#email">The email field is empty. It's a required field and must be filled in.</a>
      </li>
      <li>
        <a id="error-message" href="#message">The message field is empty. It's a required field and must be filled in.</a>
      </li>
    </ul>
  </div>
  <div>
    <label for="name">Name</label>
    <input
      id="name"
      name="name"
      type="text"
      autocomplete="name"
      required
      aria-describedby="error-name"
    />
  </div>
  <div>
    <label for="email">E-mail</label><br>
    <input
      id="email"
      name="email"
      type="email"
      autocomplete="email"
      required
      aria-describedby="error-email"
    />
  </div>
  <div>
    <label for="message">Message</label><br>
    <textarea
      id="message"
      name="message"
      rows="5"
      cols="70"
      required
      aria-describedby="error-message"
    ></textarea>
  </div>
  <button>Send</button>
</form>

This solution would be enough if our form is sent and validated on the server. In that case, if our form is located deeper within the content, we can use the <title> of the page to report the result of the submission, since it is the first thing announced by the screen reader as soon as the page is reloaded and thus the user you know immediately if it has gone right or wrong:

<title>Message sent - Contact form</title>
<title>3 Errors - Contact form</title>

If the submission is done asynchronously and we display the feedback information, a screen reader user might not notice the change. To avoid this, as we already mentioned when notifying changes in the content, just insert it inside a <div role="alert">. As soon as you do, the screen reader will announce it and move the focus to that region.

Thus, the HTML that we would have to insert would be this:

<div role="alert">
  <h3>There are 3 errors in your form, please check it</h3>
  <ul>
    [... errors <li> ...]
  </ul>
</div>

All this information and more can be found on the W3C page dedicated to this topic, where very useful tips are given on how to notify the user of the result of submitting forms.

A11y tips: offer alternatives to any functionality

Carlos Espada — Wed, 26 Jan 2022 07:27:08 +0000

Using a mobile device allows us some interactions not available in the desktop version, such as rotating it, shaking it, using two fingers to zoom...

While offering many possibilities to enrich the user experience, it opens the door to new barriers for users with some type of disability.

For this reason, it is especially important to always offer alternatives to all these interactions so that we do not prevent anyone from enjoying them.

If your mobile version...

... can be rotated, make sure that the same information can be accessible and work both in portrait and landscape, that your design is really responsive. There are people who may be browsing with the device fixed on a support and for whom turning it is really difficult or they cannot do it.
... can update data by shaking the device, make sure you put a Reload button that allows you to do the same by clicking on it. There are people who may be browsing who cannot shake the device but can comfortably access a button marked in an accessible way.
... you can zoom by sliding two fingers on the screen, add a + and - buttons to zoom in and out. Some people can't swipe with their fingers, but with the help of assistive technology, they can hit a properly marked button.

In all these cases, it is highly recommended to keep the original function, since it is very useful and takes advantage of the capabilities offered by mobile devices. It is not about impoverishing or making the use of our websites more boring, but about enriching it by making it more diverse by adding multiple ways to enjoy them.

To do this, it is enough to think of all users, not just the vast majority. After all, who hasn't ever broken an arm and found it difficult to use a website? We have the tools to keep moving forward without leaving anyone behind.

A11y tips: let the user resize text up to 200%

Carlos Espada — Tue, 25 Jan 2022 07:33:53 +0000

In addition to being able to control the general zoom of the page, there are users who may need to be able to control only the zoom of the text. And by doing so they shouldn't lose any content or functionality, or create overlaps that didn't exist.

The minimum limit for this zoom is set at 200% by the WCAG:

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts.

For this, it is recommended to use the text sizes in relative units, with a fallback to pixels. Although browsers are increasingly capable of supporting text zoom well even if it is defined in pixels, today it is more reliable to do it with em or rem, which is somewhat more comfortable to use.

In this interesting post from The A11Y Project you can find information on how to perform the tests to see if our page meets this criteria.

A11y tips: don't remove focus indicator

Carlos Espada — Mon, 24 Jan 2022 09:47:10 +0000

Very often we use outline: 0 to remove the effect of focusing on an element. This, which initially prevents a border from wrapping around it when you click/touch on it, means that users navigating using the keyboard don't have a visual indicator of which element has focus. And we know that every interactive element needs a focus indicator.

Therefore, it is recommended to address this problem using some of these solutions:

1. Style `outline property`

Use CSS to give the outline the effect you want, for example:

button:focus {
  outline: 4px dashed black;
}

2. Style element itself

Remove the outline but design other styles for the focused element, using the CSS properties that suit you best: border, background-color, text-decoration, color... In case you choose this option, it is important to be careful not to use the color as the only element to provide information about the focus, since there may be colorblind people who are not able to distinguish between the normal state and the focus state.

button:focus {
  outline: none;
  /* any accessible style you want here */
}

3. Remove outline for mouse users only

Since the problem occurs when mouse users click/touch on an interactive element, it seems best to remove the outline for these users only. Luckily we have a well-supported CSS pseudo-class at our disposal that allows us to do something like this: :focus-within.

With good browser support we can now do something like what Lea Vérou proposes.

button:focus:not(:focus-visible) {
  outline:none;
}

This way we only remove the outline for users clicking/touching the element, and we can complete our styles using the same pseudo-class for keyboard navigation:

button:focus-visible {
  outline: 4px dashed black;
}

There are very good articles on this subject by Chris Coyier and Patrick H. Lauke.

A11y tips: report on elements being shown and hidden

Carlos Espada — Thu, 20 Jan 2022 07:38:44 +0000

Sometimes we use elements that, by clicking a button, can _change their state from hidden to visible or vice versa. This is the case of a drop-down menu or an accordion, for example. And how can we inform the user of a screen reader of these changes? With the ARIA attribute aria-expanded.

So, for example, we can find something like this:

<button aria-expanded=”false”>Menu</button>
<!-- initially hidden -->
<div class="menu">
[...]
</div>

And using the same JavaScript that triggers the <button> and displays the menu, we change the value of the aria-expanded attribute:

<button aria-expanded=”true”>Menu</button>
<!-- will appear visible -->
<div class="menu menu--is-visible">
[...]
</div>

As seen in the example, the ideal is that the content that is shown or hidden is located just after the control responsible for its visibility, so that when the user activates it, it is right next to it and navigation is more logical.

Although we could use the same system for an accordion, these can be a special case as there are some HTML elements that offer the same behavior natively without the need to use ARIA or JS: the <details>-<summary> combination.

Disadvantages? It is not supported by Internet Explorer and is still somewhat buggy on some assistive technologies, so we still need to test them using keyboard and screen readers. To follow the evolution of their support and to know when we can use them without any problem, you can check HTML5 Accessibility.

A11y tips: use landmarks

Carlos Espada — Wed, 19 Jan 2022 08:23:41 +0000

Even if the usage of landmarks is in continuous decline among users of assistive technologies, they are still a very used resource for navigation, and if they are not used more often it may be due to the improper usage that we, developers, tend to make of them.

Landmarks are used to define specific regions within the structure of our HTML. Remember that all content should be included within a landmark, except, if you like, the skip link.

Landmarks have an implicit role, so in theory it is not necessary to assign it unless they are repeated in the document. On this subject there are contrary opinions that advocate declaring it explicitly to ensure compatibility with any browser. These are some of the most used:

<header> (role=”banner”)
<main> (role=”main”)
<aside> (role=”complementary”)
<footer> (role=”contentinfo”)
<nav> (role=”contentinfo”)

`<header>`

If, in addition to the main header, it is used more than once in the document to mark the header of other areas (eg: <section> or <article>), it must be indicated that the main header has a role="banner" to set it apart from the others.

<header role="banner"> can only appear once in each document.

`<main>`

By identifying the main content of the page only one can be used in each document. It must exist in a mandatory way, there may be pages that are missing any other landmark but all of them must always have a single <main> element.

`<aside>`

To know if a content has to go in an <aside> we can ask ourselves the following two questions: Is this content complementary to the main one being at the same hierarchy level? Can it be separated from it and still make sense? If the answer is yes in both cases, then it is an <aside>.

`<footer>`

If, in addition to the main footer, it is used more than once in the document to mark the footer of other areas (eg: <section> or <article>), it must be indicated that the main footer has a role="contentinfo" to set it apart from the others.

<footer role="contentinfo"> can only appear once in each document.

`<nav>`

It can appear several times in the same document, since it is used to mark important blocks of navigation (eg: main menu, footer sitemap...), but it should not be used excessively to mark each small group of links.

If it appears more than once, add an aria-label attribute to the <nav> that identifies what type of navigation it represents, for example:

<nav aria-label="Main">
<nav aria-label="Sitemap">

Avoid the role of the landmark as part of the value of aria-label. For example, a <nav> will be announced with the word "Navigation" at the end, so if we use an aria-label="Main navigation" it will be announced as "Main navigation Navigation", which is redundant. If we just use aria-label="Main" the user will just hear "Main Navigation", which is nicer.

`role="search"`

Although the default role of an HTML element should not be changed, this is a particular case that arises from the agreement between specs writers and screen reader developers, so that users of assistive technologies can jump directly to the site's search form if we use this:

<form role="search">

These are just some of the landmarks at our disposal, but to get to know them all in depth there is a lot of interesting information in the corresponding section of the W3C page.

A11y tips: autocomplete your form fields

Carlos Espada — Mon, 17 Jan 2022 07:41:44 +0000

The autocomplete attribute allows the user agent to automatically fill in certain form fields by obtaining the value from previous past values entered by the user, or from pre-configured values. It can be very useful for users with a cognitive disability, as well as for any user does not have to be repeating the same information over and over again in different forms.

<label for="first-name">First Name</label>
<input
  id="first-name"
  name=”first-name”
  type="text"
  autocomplete="given-name"
/>
<label for="last-name">Last Name</label>
<input
  id="last-name"
  name=”last-name”
  type="text"
  autocomplete="family-name"
/>

The W3C and MDN pages provide a complete list of the values that the autocomplete attribute can take. The more consistent the use of these values is throughout the entire site, the easier it will be for the user agent to use them correctly and usefully for the user.

In order to provide autocompletion, user-agents might require form fields (<input>, <select> and <textarea>) elements to:

Have a name and/or id attribute
Be descendants of a <form> element
The form to have a submit button

There are form fields that you should be careful with when using autocomplete attribute, as they contain sensitive information, such as those related to credit cards.

Some of the values are based on US formats, so usage in other countries may be difficult to resolve for the user agent.

A11y tips: accesible images

Carlos Espada — Fri, 14 Jan 2022 08:28:23 +0000

Depending on the function they fulfill, we can distinguish two types of images:

Those that provide information, such as the image that accompanies the news in a newspaper.
Those that fulfill a purely decorative function, such as a calendar icon next to a datepicker

When we insert an image in our HTML using the <img> tag we always have to accompany it with its alt attribute, so that screen readers have alternative content to announce when they reach it.

If we choose not to add the alt attribute, when the screen reader reaches the image, it will not know how to describe it and will try to do so by reading the name of the file, which could well be something like image-header.jpg, which does not provide any information.

Decorative images

The theory says that the content must be separated from the presentation, that is, that an HTML must have meaning by itself without having to rely on CSS.

For this reason, images that do not fulfill any informative function, that is, that are for purely decorative reasons, should be included in the CSS using the background-image property.

Thus, in the example of the button that we mentioned, the most correct would be something like this:

.button-date {
   background-image: url("ico-calendar.svg");
}

Sometimes these images, due to integration needs, cannot be output to external CSS files, but they can still be included inline using the style attribute. It is not optimal when mixing presentation and content, but it is still valid:

<button style="background-image: url("ico-calendar.svg")>
  Pick date
</button>

And sometimes, for whatever reason, you have to include a decorative image using the <img> tag. It is something to avoid, but if needed it can be done by leaving the alt attribute empty, so that screen readers ignore the image by not adding it to the accessibility tree.

<img src="ico-calendar.svg" alt="" />

What is the difference between not including alt attribute or leaving it empty? If you do not include it, the screen reader does not know if you have forgotten to do it but the image is still important, so it will try to offer an alternative content in any way it can, and as we have commented before it will announce the name of the file. However, if you leave the alt attribute empty you are clearly saying "hey, screen reader, I have not forgotten anything, this image is decorative and you do not have to advertise it, skip it".

Informative images

In this case we have to write a good alt attribute that describes the image and how? Trying to be as brief and at the same time descriptive of the accompanying image. It can come in handy to try to answer this question: how would we tell the content of an image to someone who cannot see it so that they have reliable information but we do not bore them?

Since the screen reader already announces previously that the <img> element is an image, it is not necessary to start the alt with texts such as Image of or similar, directly the descriptive text. For example:

<img
  src="dog.jpg"
  alt="Dog with a bell attached to its collar."
/>

If the image serves as a link, the alt attribute that we add will serve to give the link an accessible name that can be read by the screen reader.

More information on how to handle informational images can be found on the W3C-WAI page.

A special case are images that, by their very nature, have so much information that it is impossible to summarize it in an alt attribute, such as diagrams, graphs, flow charts...

In these cases there are two alternatives to offer the alternative content:

Describe the image using an HTML element located below the image, for example a <figcaption> if the image is inside a <figure>.
Make a different page with the content of the infographic and add a link to it below the image, so that the screen reader user has easy access to discover its content.

A good consequence of both options is that in addition to improving accessibility, SEO is also improved by offering more easily indexable content as it is in text format.

Still have questions?

In case you don't know how to act with an image or how to write the alt attribute, there is a very useful resource that the W3C-WAI offers, the Alt Decision Tree.

A11y tips: hide content from screen readers

Carlos Espada — Thu, 13 Jan 2022 07:28:19 +0000

If you want to hide content for screen readers but still be available to sighted or keyboard users, just use aria-hidden="true".

A classic example where it is useful is to hide icons that serve as visual support for a text:

<style>
  .icon-star: before {content: "★"; }
</style>

<span>
  <span class="icon-star" aria-hidden="true"></span>
  Favorite
</span>

In this way the icon that we insert with CSS only appears for sighted users, while screen readers will announce only "Favorite", instead of "Black Star Favorite".

It is best to avoid using this ARIA attribute on focusable elements, as being able to receive focus but hiding from screen readers can cause confusion for their users. You could use a tabindex="- 1" to avoid focus but then it would be out of use for sighted keyboard users.

This and other tips on the use of aria-hidden="true" can be found in the already named article by Scott O'Hara, and on the use of icon fonts in the article by Zach Leathermann, from which the example is taken.

A11y tips: hide content only from sighted users

Carlos Espada — Wed, 12 Jan 2022 07:11:44 +0000

Very often we want to hide items from view but we want them to still be available to screen readers and keyboard users. There are two methods for this:

Hide with CSS

This is the most common method, and works best to hide text from sighted users without any disadvantage to others.

.hidden {
  overflow: hidden;
  clip: rect (1px, 1px, 1px, 1px);
  clip-path: inset (50%);
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  border: 0;
  word-wrap: normal;
}

The clip-path property is not supported by all browsers, so we also use the clip property for those cases, even if it is deprecated.

We use a width and a height of 1px instead of 0 because in this case some screen readers could interpret that the element does not exist, as it has no dimensions, and therefore not announce it.

The word-wrap property must be declared since, having a width of 1px, some screen readers can interpret that the text is arranged vertically as it does not fit horizontally, and read it letter by letter. By declaring word-wrap like this, we avoid it and it is pronounced normally.

EDITED: Even if WebAIM or the United States Government uses a margin: -1px, as @inhuofficial comments (thank you very much for all the help! 🙂) it can cause an error with VoiceOVer, so it is better to leave it outside the CSS class, although in many places you will see that it is included. Scott O'Hara himself also leaves it out in his magnificent article Inclusively Hidden.

CSS `opacity: 0`

It has the same result as the previous one, but as we saw in the case of the CSS visibility: hidden property, here the dimensions of the element are maintained (width and height), which makes it take up space in the layout even if it is hidden, therefore its use is a lot less common.