From d596e86a4f13b04981f51d327af257b07e6d21c3 Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Sun, 14 Nov 2021 14:23:22 +0100 Subject: Prepare Learning Area section for Markdown conversion (#2738) * Remove summary, spans and fonts * Remove notranslate class * Remove ids other than headings * Remove hidden blocks * fix livesample call with exclamation mark * fix livesample call with exclamation mark * fix livesample call with exclamation mark * fix livesample call with exclamation mark * Fix notes * Remove code in pre, sub/sup and some styles * fix dls * fix absolute / english links * fix figures and others * fix other issues from report * Fix other one-off issues excl. imgs * Fix images * Fixes #2842 for Learning area --- .../learn/accessibility/wai-aria_basics/index.html | 102 ++++++++++----------- 1 file changed, 51 insertions(+), 51 deletions(-) (limited to 'files/fr/learn/accessibility/wai-aria_basics') diff --git a/files/fr/learn/accessibility/wai-aria_basics/index.html b/files/fr/learn/accessibility/wai-aria_basics/index.html index a9990d7f55..c7821400cf 100644 --- a/files/fr/learn/accessibility/wai-aria_basics/index.html +++ b/files/fr/learn/accessibility/wai-aria_basics/index.html @@ -19,62 +19,62 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics
{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}
-

Après l'article précédent, il peut être difficile de créer des contrôles UI complexes impliquant du code HTML non sémantique et du contenu dynamique mis à jour par JavaScript. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant une sémantique supplémentaire que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser pour informer les utilisateurs de ce qui se passe. Nous montrerons ici comment l'utiliser au niveau de base pour améliorer l'accessibilité.

+

Après l'article précédent, il peut être difficile de créer des contrôles UI complexes impliquant du code HTML non sémantique et du contenu dynamique mis à jour par JavaScript. WAI-ARIA est une technologie qui peut aider à résoudre de tels problèmes en ajoutant une sémantique supplémentaire que les navigateurs et les technologies d'assistance peuvent reconnaître et utiliser pour informer les utilisateurs de ce qui se passe. Nous montrerons ici comment l'utiliser au niveau de base pour améliorer l'accessibilité.

- +
- + - - + +
  Prerequis:Connaissances informatiques de base, une compréhension de base de HTML, CSS et JavaScript, une compréhension des articles précédents du cours.Connaissances informatiques de base, une compréhension de base de HTML, CSS et JavaScript, une compréhension des articles précédents du cours.
Objectif :Se familiariser avec WAI-ARIA et savoir comment l'utiliser pour fournir une sémantique supplémentaire utile afin d'améliorer l'accessibilité, le cas échéant.Objectif :Se familiariser avec WAI-ARIA et savoir comment l'utiliser pour fournir une sémantique supplémentaire utile afin d'améliorer l'accessibilité, le cas échéant.
-

Qu'est WAI-ARIA?

+

Qu'est WAI-ARIA?

-

Commençons par regarder ce que WAI-ARIA est , et ce qu’il peut faire pour nous.

+

Commençons par regarder ce que WAI-ARIA est , et ce qu’il peut faire pour nous.

-

Un nouvel ensemble de problèmes

+

Un nouvel ensemble de problèmes

Car les applications web ont commencé à devenir plus complexes et dynamiques, un nouvel ensemble de fonctionnalités d'accessibilité et de problèmes ont commencé à apparaître.

-

Par exemple, HTML5 a introduit un certain nombre d’éléments sémantiques pour définir des fonctionnalités de page communes  ({{htmlelement("nav")}}, {{htmlelement("footer")}}, etc.)  Avant de les utiliser, les développeurs utilisaient simplement {{htmlelement("div")}} s avec des identifiants ou des classes, par exemple <div class="nav"> , mais ils posaient problème, car il n’existait pas de moyen facile de trouver facilement une fonctionnalité de page spécifique telle que la navigation principale par programmation. .

+

Par exemple, HTML5 a introduit un certain nombre d’éléments sémantiques pour définir des fonctionnalités de page communes  ({{htmlelement("nav")}}, {{htmlelement("footer")}}, etc.)  Avant de les utiliser, les développeurs utilisaient simplement {{htmlelement("div")}} s avec des identifiants ou des classes, par exemple <div class="nav"> , mais ils posaient problème, car il n’existait pas de moyen facile de trouver facilement une fonctionnalité de page spécifique telle que la navigation principale par programmation. .

-

La solution initiale consistait à ajouter un ou plusieurs liens cachés en haut de la page pour créer un lien vers la navigation (ou autre), par exemple:

+

La solution initiale consistait à ajouter un ou plusieurs liens cachés en haut de la page pour créer un lien vers la navigation (ou autre), par exemple:

-
<a href="#hidden" class="hidden">Passer à la navigation</a>
+
<a href="#hidden" class="hidden">Passer à la navigation</a>
-

Mais ceci n’est pas encore très précis et ne peut être utilisé que lorsque le lecteur d’écran lit en haut de la page.

+

Mais ceci n’est pas encore très précis et ne peut être utilisé que lorsque le lecteur d’écran lit en haut de la page.

-

Autre exemple, les applications ont commencé à comporter des commandes complexes telles que des sélecteurs de date pour choisir les dates, des curseurs pour choisir des valeurs, etc. HTML5 fournit des types spéciaux  input pour rendre de tels contrôles:

+

Autre exemple, les applications ont commencé à comporter des commandes complexes telles que des sélecteurs de date pour choisir les dates, des curseurs pour choisir des valeurs, etc. HTML5 fournit des types spéciaux  input pour rendre de tels contrôles:

<input type="date">
 <input type="range">
-

Celles-ci ne sont pas bien prises en charge sur tous les navigateurs et il est également très difficile de les nommer, ce qui les rend peu utiles pour l'intégration aux conceptions de sites Web. En conséquence, les développeurs font souvent appel à des bibliothèques JavaScript qui génèrent des contrôles tels qu'une série d'éléments {{htmlelement("div")}} s imbriqués ou d'éléments de table avec des noms de classe, qui sont ensuite stylés à l'aide de CSS et contrôlés à l'aide de JavaScript.

+

Celles-ci ne sont pas bien prises en charge sur tous les navigateurs et il est également très difficile de les nommer, ce qui les rend peu utiles pour l'intégration aux conceptions de sites Web. En conséquence, les développeurs font souvent appel à des bibliothèques JavaScript qui génèrent des contrôles tels qu'une série d'éléments {{htmlelement("div")}} s imbriqués ou d'éléments de table avec des noms de classe, qui sont ensuite stylés à l'aide de CSS et contrôlés à l'aide de JavaScript.

-

Le problème ici est que, visuellement, ils fonctionnent, mais que les lecteurs d’écran ne peuvent pas comprendre ce qu’ils sont, et on dit aux utilisateurs qu’ils peuvent voir une multitude d’éléments sans sémantique pour décrire ce qu’ils veulent dire.

+

Le problème ici est que, visuellement, ils fonctionnent, mais que les lecteurs d’écran ne peuvent pas comprendre ce qu’ils sont, et on dit aux utilisateurs qu’ils peuvent voir une multitude d’éléments sans sémantique pour décrire ce qu’ils veulent dire.

Entrez WAI-ARIA

-

WAI-ARIA est une spécification écrite par le W3C et définissant un ensemble d'attributs HTML supplémentaires pouvant être appliqués aux éléments pour fournir une sémantique supplémentaire et améliorer l'accessibilité en cas de manque. Trois caractéristiques principales sont définies dans la spécification:

+

WAI-ARIA est une spécification écrite par le W3C et définissant un ensemble d'attributs HTML supplémentaires pouvant être appliqués aux éléments pour fournir une sémantique supplémentaire et améliorer l'accessibilité en cas de manque. Trois caractéristiques principales sont définies dans la spécification:

-

Un point important sur les attributs WAI-ARIA est qu'ils n'affectent en rien la page Web, à l'exception des informations exposées par les API d'accessibilité du navigateur (où les lecteurs d'écran obtiennent leurs informations). WAI-ARIA n'affecte pas la structure de la page Web, le DOM, etc., bien que les attributs puissent être utiles pour sélectionner des éléments par CSS.

+

Un point important sur les attributs WAI-ARIA est qu'ils n'affectent en rien la page Web, à l'exception des informations exposées par les API d'accessibilité du navigateur (où les lecteurs d'écran obtiennent leurs informations). WAI-ARIA n'affecte pas la structure de la page Web, le DOM, etc., bien que les attributs puissent être utiles pour sélectionner des éléments par CSS.

-

Note: Vous pouvez trouver une liste utile de tous les rôles ARIA et de leurs utilisations, avec des liens vers des informations supplémentaires, dans les spécifications WAI-ARIA — voir la définition des rôles.

+

Note : Vous pouvez trouver une liste utile de tous les rôles ARIA et de leurs utilisations, avec des liens vers des informations supplémentaires, dans les spécifications WAI-ARIA — voir la définition des rôles.

-

La spécification contient également une liste de toutes les propriétés et de tous les états, avec des liens vers des informations complémentaires - voir  Définitions des états et des propriétés (tous les attributs aria- *).

+

La spécification contient également une liste de toutes les propriétés et de tous les états, avec des liens vers des informations complémentaires - voir  Définitions des états et des propriétés (tous les attributs aria- *).

Où WAI-ARIA est supporté?

@@ -92,13 +92,13 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics
  1. Browser support is generally quite good — at the time of writing, caniuse.com stated that global browser support for WAI-ARIA was around 88%.
    2. -
  2. Screenreader support for ARIA features isn't quite at this level, but the most popular screenreaders are getting there. You can get an idea of support levels by looking at Powermapper's WAI-ARIA Screen reader compatibility article.
    3. +
  3. Screenreader support for ARIA features isn't quite at this level, but the most popular screenreaders are getting there. You can get an idea of support levels by looking at Powermapper's WAI-ARIA Screen reader compatibility article.

In this article, we won't attempt to cover every WAI-ARIA feature, and its exact support details. Instead, we will cover the most critical WAI-ARIA features for you to know about; if we don't mention any support details, you can assume that the feature is well-supported. We will clearly mention any exceptions to this.

-

Note: Some JavaScript libraries support WAI-ARIA, meaning that when they generate UI features like complex form controls, they add ARIA attributes to improve the accessibility of those features. If you are looking for a 3rd party JavaScript solution for rapid UI development, you should definitely consider the accessibility of its UI widgets as an important factor when making your choice. Good examples are jQuery UI (see About jQuery UI: Deep accessibility support), ExtJS, and Dojo/Dijit.

+

Note : Some JavaScript libraries support WAI-ARIA, meaning that when they generate UI features like complex form controls, they add ARIA attributes to improve the accessibility of those features. If you are looking for a 3rd party JavaScript solution for rapid UI development, you should definitely consider the accessibility of its UI widgets as an important factor when making your choice. Good examples are jQuery UI (see About jQuery UI: Deep accessibility support), ExtJS, and Dojo/Dijit.

When should you use WAI-ARIA?

@@ -107,24 +107,24 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics
  1. Signposts/Landmarks: ARIA's role attribute values can act as landmarks that either replicate the semantics of HTML5 elements (e.g. {{htmlelement("nav")}}), or go beyond HTML5 semantics to provide signposts to different functional areas, e.g search, tabgroup, tab, listbox, etc.
    2. -
  2. Dynamic content updates: Screenreaders tend to have difficulty with reporting constantly changing content; with ARIA we can use aria-live to inform screenreader users when an area of content is updated, e.g. via XMLHttpRequest, or DOM APIs.
    3. +
  3. Dynamic content updates: Screenreaders tend to have difficulty with reporting constantly changing content; with ARIA we can use aria-live to inform screenreader users when an area of content is updated, e.g. via XMLHttpRequest, or DOM APIs.
  4. Enhancing keyboard accessibility: There are built-in HTML elements that have native keyboard accessibility; when other elements are used along with JavaScript to simulate similar interactions, keyboard accessibility and screenreader reporting suffers as a result. Where this is unavoidable, WAI-ARIA provides a means to allow other elements to receive focus (using tabindex).
  5. Accessibility of non-semantic controls: When a series of nested <div>s along with CSS/JavaScript is used to create a complex UI-feature, or a native control is greatly enhanced/changed via JavaScript, accessibility can suffer — screenreader users will find it difficult to work out what the feature does if there are no semantics or other clues. In these situations, ARIA can help to provide what's missing with a combination of roles like button, listbox, or tabgroup, and properties like aria-required or aria-posinset to provide further clues as to functionality.
-

One thing to remember though — you should only use WAI-ARIA when you need to! Ideally, you should always use native HTML features to provide the semantics required by screenreaders to tell their users what is going on. Sometimes this isn't possible, either because you have limited control over the code, or because you are creating something complex that doesn't have an easy HTML element to implement it. In such cases, WAI-ARIA can be a valuable accessibility enhancing tool.

+

One thing to remember though — you should only use WAI-ARIA when you need to! Ideally, you should always use native HTML features to provide the semantics required by screenreaders to tell their users what is going on. Sometimes this isn't possible, either because you have limited control over the code, or because you are creating something complex that doesn't have an easy HTML element to implement it. In such cases, WAI-ARIA can be a valuable accessibility enhancing tool.

But again, only use it when necessary!

-

Note: Also, try to make sure you test your site with a variety of real users — non-disabled people, people using screenreaders, people using keyboard navigation, etc. They will have better insights than you about how well it works.

+

Note : Also, try to make sure you test your site with a variety of real users — non-disabled people, people using screenreaders, people using keyboard navigation, etc. They will have better insights than you about how well it works.

Practical WAI-ARIA implementations

In the next section we'll look at the four areas in more detail, along with practical examples. Before you continue, you should get a screenreader testing setup put in place, so you can test some of the examples as you go through.

-

See our section on testing screenreaders for more information.

+

See our section on testing screenreaders for more information.

Signposts/Landmarks

@@ -160,7 +160,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

If you go to VoiceOver's landmarks menu (accessed using VoiceOver key + U and then using the cursor keys to cycle through the menu choices), you'll see that most of the elements are nicely listed so they can be accessed quickly.

-

+

However, we could do better here. the search form is a really important landmark that people will want to find, but it is not listed in the landmarks menu or treated like a notable landmark, beyond the actual input being called out as a search input (<input type="search">). In addition, some older browsers (most notably IE8) don't recognise the semantics of the HTML5 elements.

@@ -202,7 +202,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

Content loaded into the DOM can be easily accessed using a screenreader, from textual content to alternative text attached to images. Traditional static websites with largely text content are therefore easy to make accessible for people with visual impairments.

-

The problem is that modern web apps are often not just static text — they tend to have a lot of dynamically updating content, i.e. content that updates without the entire page reloading via a mechanism like XMLHttpRequest, Fetch, or DOM APIs. These are sometimes referred to as live regions.

+

The problem is that modern web apps are often not just static text — they tend to have a lot of dynamically updating content, i.e. content that updates without the entire page reloading via a mechanism like XMLHttpRequest, Fetch, or DOM APIs. These are sometimes referred to as live regions.

Let's look at a quick example — see aria-no-live.html (also see it running live). In this example we have a simple random quote box:

@@ -213,7 +213,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics </blockquote> </section> -

Our JavaScript loads a JSON file via XMLHttpRequest containing a series of random quotes and their authors. Once that is done, we start up a setInterval() loop that loads a new random quote into the quote box every 10 seconds:

+

Our JavaScript loads a JSON file via XMLHttpRequest containing a series of random quotes and their authors. Once that is done, we start up a setInterval() loop that loads a new random quote into the quote box every 10 seconds:

var intervalID = window.setInterval(showQuote, 10000);
@@ -234,7 +234,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

This will cause a screenreader to read out the content as it is updated.

-

Note: Most browsers will throw a security exception if you try to do an XMLHttpRequest call from a file:// URL, e.g. if you just load the file by loading it directly into the browser (via double clicking, etc.). To get it to run, you will need to upload it to a web server, for example using GitHub, or a local web server like Python's SimpleHTTPServer.

+

Note : Most browsers will throw a security exception if you try to do an XMLHttpRequest call from a file:// URL, e.g. if you just load the file by loading it directly into the browser (via double clicking, etc.). To get it to run, you will need to upload it to a web server, for example using GitHub, or a local web server like Python's SimpleHTTPServer.

There is an additional consideration here — only the bit of text that updates is read out. It might be nice if we always read out the heading too, so the user can remember what is being read out. To do this, we can add the aria-atomic property to the section. Update your <section> tag again, like so:

@@ -244,11 +244,11 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

The aria-atomic="true" attribute tells screenreaders to read out the entire element contents as one atomic unit, not just the bits that were updated.

-

Note: You can see the finished example at aria-live.html (see it running live).

+

Note : You can see the finished example at aria-live.html (see it running live).

-

Note: The aria-relevant property is also quite useful for controlling what gets read out when a live region is updated. You can for example only get content additions or removals read out.

+

Note : The aria-relevant property is also quite useful for controlling what gets read out when a live region is updated. You can for example only get content additions or removals read out.

Enhancing keyboard accessibility

@@ -264,7 +264,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics
  • tabindex="-1" — this allows not normally tabbable elements to receive focus programmatically, e.g. via JavaScript, or as the target of links. 
    • -

    We discussed this in more detail and showed a typical implementation back in our HTML accessibility article — see Building keyboard accessibility back in.

    +

    We discussed this in more detail and showed a typical implementation back in our HTML accessibility article — see Building keyboard accessibility back in.

    Accessibility of non-semantic controls

    @@ -272,15 +272,15 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

    Form validation and error alerts

    -

    First of all, let's revisit the form example we first looked at in our CSS and JavaScript accessibility article (read Keeping it unobtrusive for a full recap). At the end of this section we showed that we have included some ARIA attributes on the error message box that appears when there are validation errors when you try to submit the form:

    +

    First of all, let's revisit the form example we first looked at in our CSS and JavaScript accessibility article (read Keeping it unobtrusive for a full recap). At the end of this section we showed that we have included some ARIA attributes on the error message box that appears when there are validation errors when you try to submit the form:

    -
    <div class="errors" role="alert" aria-relevant="all">
-  <ul>
-  </ul>
-</div>
    +
    <div class="errors" role="alert" aria-relevant="all">
+  <ul>
+  </ul>
+</div>
    @@ -304,14 +304,14 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics
    -

    Note: You can see the finished example live at form-validation-updated.html.

    +

    Note : You can see the finished example live at form-validation-updated.html.

    -

    WAI-ARIA also enables some advanced form labelling techniques, beyond the classic {{htmlelement("label")}} element. We already talked about using the aria-label property to provide a label where we don't want the label to be visible to sighted users (see the {{anch("Signposts/Landmarks")}} section, above). There are some other labelling techniques that use other properties such as aria-labelledby if you want to designate a non-<label> element as a label or label multiple form inputs with the same label, and aria-describedby, if you want to associate other information with a form input and have it read out as well. See WebAIM's Advanced Form Labeling article for more details.

    +

    WAI-ARIA also enables some advanced form labelling techniques, beyond the classic {{htmlelement("label")}} element. We already talked about using the aria-label property to provide a label where we don't want the label to be visible to sighted users (see the {{anch("Signposts/Landmarks")}} section, above). There are some other labelling techniques that use other properties such as aria-labelledby if you want to designate a non-<label> element as a label or label multiple form inputs with the same label, and aria-describedby, if you want to associate other information with a form input and have it read out as well. See WebAIM's Advanced Form Labeling article for more details.

    -

    There are many other useful properties and states too, for indicating the status of form elements. For example, aria-disabled="true" can be used to indicate that a form field is disabled. Many browsers will just skip past disabled form fields, and they won't even be read out by screenreaders, but in some cases they will be perceived, so it is a good idea to include this attribute to let the screenreader know that a disabled input is in fact disabled.

    +

    There are many other useful properties and states too, for indicating the status of form elements. For example, aria-disabled="true" can be used to indicate that a form field is disabled. Many browsers will just skip past disabled form fields, and they won't even be read out by screenreaders, but in some cases they will be perceived, so it is a good idea to include this attribute to let the screenreader know that a disabled input is in fact disabled.

    -

    If the disabled state of an input is likely to change, then it is also a good idea to indicate when it happens, and what the result is. For example, in our form-validation-checkbox-disabled.html demo there is a checkbox that when checked, enables another form input to allow further information be entered. We've set up a hidden live region:

    +

    If the disabled state of an input is likely to change, then it is also a good idea to indicate when it happens, and what the result is. For example, in our form-validation-checkbox-disabled.html demo there is a checkbox that when checked, enables another form input to allow further information be entered. We've set up a hidden live region:

    <p class="hidden-alert" aria-live="assertive"></p>
    @@ -335,7 +335,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

    Describing non-semantic buttons as buttons

    -

    A few times in this course already, we've mentioned the native accessibilty of (and the accessibility issues behind using other elements to fake) buttons, links, or form elements (see UI controls in the HTML accessibility article, and {{anch("Enhancing keyboard accessibility")}}, above). Basically, you can add keyboard accessibility back in without too much trouble in many cases, using tabindex and a bit of JavaScript.

    +

    A few times in this course already, we've mentioned the native accessibilty of (and the accessibility issues behind using other elements to fake) buttons, links, or form elements (see UI controls in the HTML accessibility article, and {{anch("Enhancing keyboard accessibility")}}, above). Basically, you can add keyboard accessibility back in without too much trouble in many cases, using tabindex and a bit of JavaScript.

    But what about screenreaders? They still won't see the elements as buttons. If we test our fake-div-buttons.html example in a screenreader, our fake buttons will be reported using phrases like "Click me!, group", which is obviously confusing.

    @@ -346,14 +346,14 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

    Now when you try this using a screenreader, you'll have buttons be reported using phrases like "Click me!, button" — much better.

    -

    Note: Don't forget however that using the correct semantic element where possible is always better. If you want to create a button, and can use a {{htmlelement("button")}} element, you should use a {{htmlelement("button")}} element!

    +

    Note : Don't forget however that using the correct semantic element where possible is always better. If you want to create a button, and can use a {{htmlelement("button")}} element, you should use a {{htmlelement("button")}} element!

    Guiding users through complex widgets

    There are a whole host of other roles that can identify non-semantic element structures as common UI features that go beyond what's available in standard HTML, for example combobox, slider, tabpanel, tree. You can see a number of userful examples in the Deque university code library, to give you an idea of how such controls can be made accessible.

    -

    Let's go through an example of our own. We'll return to our simple absolutely-positioned tabbed interface (see Hiding things in our CSS and JavaScript accessibility article), which you can find at Tabbed info box example (see source code).

    +

    Let's go through an example of our own. We'll return to our simple absolutely-positioned tabbed interface (see Hiding things in our CSS and JavaScript accessibility article), which you can find at Tabbed info box example (see source code).

    This example as-is works fine in terms of keyboard accessibility — you can happily tab between the different tabs and select them to show the tab contents. It is also fairly accessible too — you can scroll through the content and use the headings to navigate , even if you can't see what is happening on screen. It is however not that obvious what the content is — a screenreader currently reports the content as a list of links, and some content with three headings. It doesn't give you any idea of what the relationship is between the content. Giving the user more clues as to the structure of the content is always good.

    @@ -377,7 +377,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics </div>
    -

    Note: The most striking change here is that we've removed the links that were originally present in the example, and just used the list items as the tabs — this was done because it makes things less confusing for screenreader users (the links don't really take you anywhere; they just change the view), and it allows the setsize/position in set features to work better — when these were put on the links, the browser kept reporting "1 of 1" all the time, not "1 of 3", "2 of 3", etc.

    +

    Note : The most striking change here is that we've removed the links that were originally present in the example, and just used the list items as the tabs — this was done because it makes things less confusing for screenreader users (the links don't really take you anywhere; they just change the view), and it allows the setsize/position in set features to work better — when these were put on the links, the browser kept reporting "1 of 1" all the time, not "1 of 3", "2 of 3", etc.

    The new features are as follows:

    @@ -394,7 +394,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics

    In our tests, this new structure did serve to improve things overall. The tabs are now recognised as tabs (e.g. "tab" is spoken by the screenreader), the selected tab is indicated by "selected" being read out with the tab name, and the screenreader also tells you which tab number you are currently on. In addition, because of the aria-hidden settings (only the non-hidden tab ever has aria-hidden="false" set), the non-hidden content is the only one you can navigate down to, meaning the selected content is easier to find.

    -

    Note: If there is anything you explicitly don't want screen readers to read out, you can give them the aria-hidden="true"  attribute.

    +

    Note : If there is anything you explicitly don't want screen readers to read out, you can give them the aria-hidden="true"  attribute.

    Summary

    @@ -419,7 +419,7 @@ original_slug: Apprendre/a11y/WAI-ARIA_basics
  • Qu'est ce que l'accessibilité?
  • HTML : une bonne base pour l'accessibilité
  • Meilleures pratiques d'accessibilité CSS et JavaScript
    • -
  • WAI-ARIA basics
    • +
  • WAI-ARIA basics
  • Accessible multimedia
  • Accessibilité mobile
  • Évaluation: dépannage d'accessibilité
    • -- cgit v1.2.3-54-g00ecf