diff --git a/en/about/index.html b/en/about/index.html index 81e13a950..78db65ff4 100644 --- a/en/about/index.html +++ b/en/about/index.html @@ -160,7 +160,7 @@

About

Documentation under the CC BY SA 3.0 licence, source code of this site and examples are available on GitHub.

The Orange logo and some images or screenshots are property of Orange:

Copyright (C) 2016 - 2025 Orange SA All rights reserved

- +

You can change your preferences at any time directly from the Cookie Management Panel.

diff --git a/en/accessibility-user-testing/index.html b/en/accessibility-user-testing/index.html index b0b15b5a0..ac0656c42 100644 --- a/en/accessibility-user-testing/index.html +++ b/en/accessibility-user-testing/index.html @@ -157,7 +157,7 @@

Orange digital accessibility guidelines

-

Accessibility user testing #

+

Accessibility user testing #

In order to evaluate the accessibility of a site, application, or product, accessibility experts conduct audits with the objective to check their compliance against standard or best practices rules (WCAG 2.1 Level AA for web).

Once the application is compliant or mostly compliant with guidelines, experts can complete their audit with tests performed by users with disabilities.

In ergonomics: «User testing is the main method for evaluating the user experience in an iterative process. The evaluation relies on the observation of users performing a set of tasks while interacting with a system. Data collected regarding their behavior, reactions and performances provide information about strengths and weaknesses of the evaluated system, as well as about the experience of users.» (translated from Méthodes de design UX. Carine Lallemand & Guillaume Gronier. Eyrolles, 2016).
diff --git a/en/articles/accessible-table/index.html b/en/articles/accessible-table/index.html index d8b3c6016..bc2e6f414 100644 --- a/en/articles/accessible-table/index.html +++ b/en/articles/accessible-table/index.html @@ -186,29 +186,29 @@

Tables in accessibility

-

General presentation #

+

General presentation #

A table is an arrangement of information in rows and columns containing cells that make it easy to compare and highlight information. They allow tabular information to be presented in a two-dimensional grid, such data is easier to read in tabular form.

This allows a user, who does not have a vision problem, to quickly make visual associations between table data and its table headings.

However, a blind user will not have access to all these relations between the information, it's the reason why it is important that the tables are implemented with the appropriate HTML markup so that they are the most accessible possible for assistive technologies.

In the rest of this article, we will see the main rules to follow to obtain an accessible table.

-

Add a caption/title to your table #

+

Add a caption/title to your table #

It is important to define a title for your table. Concise and relevant, this text will indicate its content as well as the type of data it contains.
It must be associated with the table using the caption element and must be the first element after the opening table tag. You can also use a h1,h2... title placed in the code just before the table as another way to associate a title.

-

Example caption #

+

Example caption #


 <table>
     <caption>Time planning 2022</caption>
     [...]
 </table>
 
-

Example HTML title #

+

Example HTML title #


 <h2>Time planning 2022</h2>
 <table>
     [...]
 </table>
 
-

Add a description for complex table #

+

Add a description for complex table #

If you have a complex table and want to provide a more detailed summary, it is recommended to use the ARIA aria-describedby attribute.
It will programmatically link a description to your table.


@@ -222,8 +222,8 @@ 

Add a description for complex table </table>

There is also the possibility of using the summary attribute to give, in addition, a summary of the contents of a table, however this attribute is no longer part of the HTML 5 specifications and we do not recommend its use.

-

Identify your table headers #

-

Scope attribute #

+

Identify your table headers #

+

Scope attribute #

To help assistive technology users, you must identify table headings, whether for rows or columns.
To identify these table headers, you must use the th tag, which must never be empty.

Once the headers are created, the data cells must be associated with the headers on which they rely.
@@ -232,7 +232,7 @@

Scope attribute for a column header
  • <th scope="row"> for a row header
  • -

    Id and header attributes #

    +

    Id and header attributes #

    Some tables are too complex to identify a strict horizontal or vertical association (for example, merged columns or rows) between the header and the data cells.
    The scope attribute does not solve this problem. A unique id attribute must be used for each header cell. To link this header to a cell, you must use the headers attribute and adding the required id.

    For example, we have two header cells, <th id="toto">Toto</th> and <th id="tata">Tata</ th>, the code to link it to a data cell will be <td headers="toto tata">Tota</td>.

    @@ -241,16 +241,16 @@

    Id and header attributes Navigating a table using NVDA or JAWS #

    +

    Creating accessible tables will allow consistent reading of these tabular data with a screen reader. To navigate in a table with Jaws or NVDA, there are several specific shortcuts.

    -

    NVDA #

    +

    NVDA #

    To quickly navigate from table to table in a page, just use the t key, if you use the Shift + t shortcut, you navigate in the opposite direction and so we return to the previous table.

    Once inside a table, there are several shortcuts to move around easily.

    -

    Jaws #

    +

    Jaws #

    For Jaws, you have to use the Y key and Shift + Y to navigate between tables.
    To browse in tables, there are several shortcuts:

    -

    Table example #

    +

    Table example #

    We will now show you examples of accessible tables.

    -

    Simple table #

    +

    Simple table #

    The first example is a table with only headers on the columns, so we use the scope="row" attribute for assistive technologies to interpret it correctly.

    @@ -322,7 +322,7 @@

    Simple table

    Like this, it is possible to easily navigate within the table using a screen reader. Also, any cell change from one column, or row, to another, the header will be vocalized.

    For example, if we are positioned on the First name column, and we use the shortcut Ctrl+alt+right arrow to go to the Last name column, NVDA vocalizes "Last Name Column 2 + column text ".

    -

    Tables with Two Headers #

    +

    Tables with Two Headers #

    In this second example, the table is a planning time allowing you to quickly know whether the store is open or not, depending on the day of the week and the time.

    This table requires two headers, one for the days of the week and another for the time slot.

    People with their professional activity
    @@ -388,7 +388,7 @@

    Tables with Two Headers Complex table #

    +

    Complex table #

    In this example, some given cells have three associated headers, so we have to use the id and headers attributes.

    Since the table is complex, we can add a description to help users understand the table.

    Tables for calculating the compliance rate of a website.
    diff --git a/en/articles/aria-attributes-that-can-save-you/index.html b/en/articles/aria-attributes-that-can-save-you/index.html index a8a6dc18d..4d1d2863a 100644 --- a/en/articles/aria-attributes-that-can-save-you/index.html +++ b/en/articles/aria-attributes-that-can-save-you/index.html @@ -186,12 +186,12 @@

    ARIA attributes that can save you

    -

    Introduction #

    -

    Accessible name and description #

    +

    Introduction #

    +

    Accessible name and description #

    An accessible name is the information that allows assistive technology (AT), for example, a screen reader or a magnification program, to identify a given element (HTML tag). It can be provided by the title or content of an element, an attribute (for example, an alt attribute for an image) or by an associated element (for example, a label tag for a input field).

    An accessible description is more extensive information that is used by the AT allowing it to complete the accessible name by specifying and adding meaning where the accessible name is not sufficient.

    The accessible name as the accessible description can be visually noticeable or not (link title: visible, alternative image: hidden and usable only by AT...)

    -

    ARIA attributes: aria-label, aria-labelledby and aria-describedby #

    +

    ARIA attributes: aria-label, aria-labelledby and aria-describedby #

    Three ARIA attributes are very well supported by browsers and AT: aria-label, aria-labelledby and aria-describedby. They allow to add extra information to an HTML tag:

    For any other HTML element, these three ARIA attributes have few or even random support depending on the AT / browser pair, so do not use as the only way of giving necessary information.

    -

    Should it be used and how? #

    +

    Should it be used and how? #

    Yes, we can use these three ARIA attributes on the elements with which it works (see above) to pass essential information specifically to AT.

    You should know that aria-label must contain, as a value, a string of characters that will be the accessible name. While for aria-labelledby and aria-describedby, the value of this attribute references one or more (space separated) id (auto referencing possible) of page elements whose content will be used as the accessible name of the element.

    When using aria-label or aria-labelledby on an element, the content or title of that element is no longer rendered to AT but replaced by the accessible name (for aria-label the contents of this attribute, for aria-labelledby the contents of the referenced element). Therefore, only the accessible name must give all the necessary information to AT and therefore to the user.

    Important: attribute aria-labelledby can admit several values separated by a space and can self-refer. It also works with pseudo-class generated content CSS ::before or ::after. You can also reference content that is visually hidden by: CSS, visibility: hidden; or display: none;, and with the HTML5 attribute hidden. However, best practices require that if the interface is such that it is not possible to have a visible text label on the screen, it is better to use aria-label rather than aria-labelledby.

    When the two attributes aria-labelledby and aria-label are used, user agents give priority to aria-labelledby when calculating the accessible name property.

    At last, `aria-describedby' will add an accessible description in addition to the accessible name of the element.

    -

    Examples #

    +

    Examples #

    
     <button aria-label="Access html (Hypertext markup language)">html</button>
     
    diff --git a/en/articles/aria-live-alert/index.html b/en/articles/aria-live-alert/index.html index 38bddcb3c..8d0b42194 100644 --- a/en/articles/aria-live-alert/index.html +++ b/en/articles/aria-live-alert/index.html @@ -187,24 +187,24 @@

    The aria-live attribute and the role alert

    Users who navigate using a screen reader are not always aware of changes made on the page. When information is updated or when a message appears, it is sometimes necessary to make the screen reader speak to inform the user. To do this, the ARIA language has the role alert and the attribute aria-live.

    -

    The role alert #

    +

    The role alert #

    Positioned on an HTML element, this allows you to tell the screen reader to vocalize the element automatically when it is created. However, be sure to use this role only in appropriate cases, as clearly stated in the Mozilla MDN documentation. Due to its intrusive nature, role alert should be used sparingly and only in situations where the user's attention is immediately required. Less urgent dynamic changes should use a less aggressive method, such as aria-live="polite" or other live zone roles.

    To trigger an alert, several methods are possible, with a support that differ depending on the browser and screen reader pair used. You can read Steve Faulkner's article on this subject.

    Here are some examples of methods that are well supported.

    -

    Create a new element in the DOM #

    +

    Create a new element in the DOM #

    You can trigger an alert by inserting a new element in the DOM via Javascript.

      <span role="alert"> This is an alert message. </span>  
    -

    Add a role alert on an existing element #

    +

    Add a role alert on an existing element #

    The triggering of an alert can also be done by adding a role="alert" dynamically to an existing element via Javascript.

     
     document.getElementById('alert').setAttribute("role", "alert");
      
    -

    Using innerHTML #

    +

    Using innerHTML #

    Create an alert via the innerHTML property.

     
     element.innerHTML = '<div role ="alert">This is an alert</div>';
      
    -

    The aria-live attribute #

    +

    The aria-live attribute #

    Positioned on an HTML element, the aria-live attribute is used to indicate to the screen reader that any modification made to its content will result in vocalization by the screen reader.

    Three values ​​are possible:

      @@ -222,7 +222,7 @@

      The aria-live att
    • aria-relevant: indicates which type of change triggers a vocalization, possible values: additions (default), removals, all.

    Finally, to be complete, know that the ARIA language also provides for some specific roles, status and log in particular which can be useful in certain cases (status bar, logging, chat...) and which, for the moment, must be used in addition to the aria-live attribute to maximize support by the different tools. You can find more info on these roles in the links below.

    -

    References #

    +

    References #

    • Use of the alert role
    • ARIA live zones
    • diff --git a/en/articles/aria-status-messages/index.html b/en/articles/aria-status-messages/index.html index eaab57068..fa8b786bb 100644 --- a/en/articles/aria-status-messages/index.html +++ b/en/articles/aria-status-messages/index.html @@ -186,9 +186,9 @@

      Use ARIA for status messages

      -

      Status message and accessibility #

      +

      Status message and accessibility #

      The WCAG 2.1 criterion 4.1.3 Status Messages requires that important informations for the user, which do not induce a change of context (no opening of a new window, no focus on the content, no modification of the content or the viewport), are seen via properties and roles (ARIA) by anyone using AT without taking focus on the message.

      -

      Some examples of status messages #

      +

      Some examples of status messages #

      When a user presses a search button, the content of the page is updated asynchronously to add the search results displayed in a region below the search button. The message "XX results found" is at the top of this new content. A screen reader will have to announce "XX results have been found". In this case, the information provided to the user is important and must be given immediately, so we will use the role "alert".

      <h2 role="alert">
           5 results were found
      @@ -233,7 +233,7 @@ 

      Some examples of stat </div>

      Sometimes we want to provide messages only for screen readers, without having to display them visually. In this case too, you need to use these ARIA roles to push the message to AT and in particular to the screen readers without displaying them on the screen.

      -

      Status messages that are not! #

      +

      Status messages that are not! #

      The basic rule is that if the focus is moved or the context is returned to users of AT, it is not a status message:

      • a modal that requires a user action, on which the focus is set
      • diff --git a/en/articles/autocomplete-component/index.html b/en/articles/autocomplete-component/index.html index 86fc51e9f..b07f570db 100644 --- a/en/articles/autocomplete-component/index.html +++ b/en/articles/autocomplete-component/index.html @@ -191,7 +191,7 @@

        Guidelines for the accessibility of an autocompletion component

        We therefore decided to carry out an inventory in order to define several functional guidelines.

        The end goal is to offer a ready-to-use component for projects.

        In this article, we present our method and the guidelines adopted.

        -

        Our method #

        +

        Our method #

        We want to build on existing patterns wherever possible.

        First, upstream audits are carried out on several components by an accessibility expert in order to ensure an initial selection.

        The most usable components are then subjected to user tests.

        @@ -200,7 +200,7 @@

        Our method GOV UK, accessible autocomplete (new window)
      • Pattern WAI ARIA 1.1, combobox (new window)
      -

      User tests #

      +

      User tests #

      We contacted Orange employees with disabilities.

      • Documentalist, JAWS and IE11 user
      • @@ -219,7 +219,7 @@

        User tests

        -

        Summary of feedbacks #

        +

        Summary of feedbacks #

        with JAWS:

        In the ARIA versions, examples 2 and 3, the user is not informed that this is an autocompletion field.

        with NVDA:

        @@ -235,7 +235,7 @@

        Summary of feedbacks

        with ZoomText:

        The user does not see any significant differences between the four implementations.

        -

        Mobile tests #

        +

        Mobile tests #

        In addition, mobile tests are carried out by accessibility experts on the same test pages.

        Tested versions:

        -

        Conclusion of tests #

        +

        Conclusion of tests #

        It appears that with the assistive technologies and browers tested, the implementation of GOV UK is more robust.

        The ARIA pattern relies on focus management by aria-activedescendant, unlike the GOV UK component which relies on the focus()method.

        It's possible that these different implementations that impacts the behavior on mobile.

        @@ -263,10 +263,10 @@

        Conclusion of tests #

        +

        Guidelines #

        You understand, we relied heavily on the GOV UK component.

        The differences with the initial component are commented directly in the guidelines.

        -

        Combobox #

        +

        Combobox #

        Input text with the following attributes:

          @@ -288,7 +288,7 @@

          Combobox Differences between ARIA 1.0 and 1.1: Changes (new window) -

          Listbox #

          +

          Listbox #

          UL element with the following attributes:

            @@ -313,7 +313,7 @@

            Listbox Feedback messages #

            +

            Feedback messages #

            • A message to indicate the interactions, example from GOV UK:
            @@ -344,7 +344,7 @@

            Feedback messages Interactions #

            +

            Interactions #

            • Enter the proposals: down arrows (input to first item)
            • Navigation between the proposals: up and down arrows (no tabulation)
            • @@ -384,7 +384,7 @@

              Interactions
            • The arrows allow you to reposition yourself in the combobox, again we choose to align ourselves with the native behavior (unlike this time the ARIA 1.2 pattern draft )
            • -

              Resources #

              +

              Resources #

              • GOV UK, accessible autocomplete (new window)
              • Article We're building an autocomplete (new window)
              • diff --git a/en/articles/captcha-accessibility/index.html b/en/articles/captcha-accessibility/index.html index c45d6c266..b70a599de 100644 --- a/en/articles/captcha-accessibility/index.html +++ b/en/articles/captcha-accessibility/index.html @@ -186,12 +186,12 @@

                CAPTCHA Accessibility

                -

                Introduction #

                +

                Introduction #

                A CAPTCHA (“Completely Automated Public Turing-test to tell Computers and Humans Apart”) is an automated test aimed at telling apart a human user from a software program. It is often used on forms to prevent spam.
                There are several types of CAPTCHAs, most of them are visual tests that ask the user to type a series of deformed letters displayed on the screen.

                Visual captcha screenshot
                Example of a visual CAPTCHA

                -

                First analysis: CAPTCHAs and users #

                +

                First analysis: CAPTCHAs and users #

                CAPTCHAs are often problematic, even for savvy users. It is often necessary to undergo several trials before giving the right answer to a CAPTCHA. For some users a CAPTCHA is a no-go, plain and simple. For example a blind user cannot solve a visual CAPTCHA. Even if some sites provide alternatives, like audio CAPTCHAs in addition to visual CAPTCHAs, it actually seldom works. It’s even the first source of difficulty quoted by visually impaired users according to WebAIM’s latest survey at the end of 2017:

                Graph from webaim survey

                CAPTCHAs pointed out by visually impaired users as most common annoyance (2017 WebAIM survey)

                @@ -202,23 +202,23 @@

                First analysis: CAPT No CAPTCHA by Google

                Even if this solution is more efficient, it is still not satisfactory from an accessibility point of view because, in case of doubt, a standard CAPTCHA is displayed. It is often the case for a user who does not use a mouse but a keyboard, or for a screen reader user (visually impaired users). You must thus always provide an alternative contact means (email, telephone, etc.) in the case when the CAPTCHA cannot be filled.
                Between users that cannot input the CAPTCHA text and those who don’t understand what’s expected of them, adding a CAPTCHA is not benign regarding the audience of a site. Considering CAPTCHAs are problematic to many users, the first recommendation is to not use a CAPTCHA.

                -

                Second analysis: CAPTCHA and security #

                +

                Second analysis: CAPTCHA and security #

                In a 2014 article by Google, we read that artificial intelligence get a 99.8% score when solving “even the most difficult variant of distorted text” – thus getting a better score than a real user! Services can guess which font was used in an image, or whether the image contains an object (a cat, a car, a hat, etc.). Same conclusion in this more recent article Breaking CAPTCHA Using Machine Learning in 0.05 Seconds.
                Considering this (users bouncing from the site in frustration and uncertain security), we come back to our first recommendation: do not use a CAPTCHA.

                - +

                Our idea is, first, to determine risks and to ask ourselves the following questions:

                • What are the risks in case of an attack?
                • What is the real need, between bouncing bots off and providing a secured solution?

                According to our answers, we will be able to provide the solution most fit to the problem.

                -

                HoneyPot and Time measuring, two simple techniques to put in place to identify bots #

                +

                HoneyPot and Time measuring, two simple techniques to put in place to identify bots #

                These two techniques are transparent for the user, and the risks they pose are very limited.
                The first solution consists in adding a hidden field in the form. This will never be filled by a user. If you detect server-side that the field was filled, it must be malevolent software.
                The second technique consists in measuring the time it takes for the user to fill the form. If it is very fast, there’s a good chance that it’s malevolent software.

                -

                Anti-spam and denylist solutions to remove bot requests #

                +

                Anti-spam and denylist solutions to remove bot requests #

                It is also possible, server-side, to triage information with anti-spam software and automatically remove submissions from malevolent software by analysing content data and the originating IP.

                -

                A logical or mathematical test, also called textual CAPTCHA #

                +

                A logical or mathematical test, also called textual CAPTCHA #

                This is done through a simple sentence asking the user to copy a word, to solve a simple mathematical operation, etc.

                • “Copy the word: ‘House’”
                • @@ -228,12 +228,12 @@

                  An email, SMS or phone verification for reinforced security #

                  +

                  An email, SMS or phone verification for reinforced security #

                  This solution consists in sending an email, an SMS or in calling directly the user to make sure they can confirm the transaction, by clicking on a link or by sending the code they received.
                  This solution is at the same time more constraining for the user who must communicate personal information and more tedious to put in place, but it’s a very efficient solution when the security level needs to be high.

                  -

                  Summary #

                  +

                  Summary #

                  There is no perfect solution, either for the user or security-wise. You should opt for the best technique according to the service provided. Also, it is important in the case of attack to have logs to analyse and to prepare for further attacks.

                  -

                  Test with real users #

                  +

                  Test with real users #

                  In any event, these captchas and their alternatives must be supplemented by user tests of assistive technologies to ensure the usability of the solution put in place.

                diff --git a/en/articles/download-links/index.html b/en/articles/download-links/index.html index b204fec6b..c1a5960f4 100644 --- a/en/articles/download-links/index.html +++ b/en/articles/download-links/index.html @@ -195,21 +195,21 @@

                Some best practices for downloading links

              • this link must open in the current window (no target attribute to open in a new tab)

              In addition, to improve accessibility, providing these informations will allow the user to avoid unnecessary downloads, which is also eco-responsible (green) best practice.

              -

              Valid examples #

              +

              Valid examples #

              Here is an example of a link with the necessary information:

              Download the complete review 2020 (PDF, 1.5 MB).

              It is important that this additional information is present in the title of the link and not just after the link (especially for people who use a screen reader). That said, for aesthetic reasons, it is possible to ensure that the additional information is not underlined, for example:

              Download the complete review 2020 (PDF, 1.5Mo)

              -

              About the units #

              +

              About the units #

              In English, the units used to express the weight of the files are written in capital letters (KbB, MB, GB...).

              -

              File language #

              +

              File language #

              For the links allowing to download a document in a language other than that of the current page, it is important to specify it.

              Examples of documents in French on a English site:

              -

              A small image for decoration, but not only #

              +

              A small image for decoration, but not only #

              If the file type is known, a small icon next to the file allows the user to identify it more quickly:
              complete review 2020 (PDF, 1.5 MB)

              diff --git a/en/articles/fact-sheet-accessibility/index.html b/en/articles/fact-sheet-accessibility/index.html index 0c831dc7c..490e71a19 100644 --- a/en/articles/fact-sheet-accessibility/index.html +++ b/en/articles/fact-sheet-accessibility/index.html @@ -189,9 +189,9 @@

              Accessibility fact sheets

              Our fact sheets on digital accessibility

              Do not forget the essential information, use our fact sheets!

              -

              What is this ? #

              +

              What is this ? #

              These are reminders available in PDF format. You can print them on a double-sided sheet and then accordion-fold them to form a small booklet to keep on hand or to share.

              -

              Fact sheets list #

              +

              Fact sheets list #

              Office documents:


              -

              Create an accessible email #

              +

              Create an accessible email #

              @@ -229,7 +229,7 @@

              Download

              -

              Create an accessible Word document #

              +

              Create an accessible Word document #

              @@ -248,7 +248,7 @@

              Download

              -

              Create an accessible Excel document #

              +

              Create an accessible Excel document #

              @@ -267,7 +267,7 @@

              Download

              -

              Create an accessible PowerPoint presentation #

              +

              Create an accessible PowerPoint presentation #

              @@ -287,7 +287,7 @@

              Download


              -

              Develop accessible web pages #

              +

              Develop accessible web pages #

              @@ -310,7 +310,7 @@

              Download


              -

              Test the accessibility of web pages #

              +

              Test the accessibility of web pages #

              @@ -334,7 +334,7 @@

              Download


              -

              Develop an accessible Android application #

              +

              Develop an accessible Android application #

              @@ -355,7 +355,7 @@

              Download


              -

              Develop an accessible iOS application #

              +

              Develop an accessible iOS application #

              diff --git a/en/articles/font-size-and-colors/index.html b/en/articles/font-size-and-colors/index.html index 9373b1ab7..de7d6879c 100644 --- a/en/articles/font-size-and-colors/index.html +++ b/en/articles/font-size-and-colors/index.html @@ -192,16 +192,16 @@

              Text size and color

            • What is the minimum font size to respect?
            • What color can I use for the text?
            -

            What do the guidelines say ? #

            +

            What do the guidelines say ? #

            The WCAG do not impose a minimum size or colors for texts. However two criteria must be taken into consideration:

            -

            Text size enlargement #

            +

            Text size enlargement #

            If the guidelines do not impose a minimum size for characters, criterion 1.4.4 indicates that the user must be able to increase text size up to 200% without loss of content or functionality. To comply with this criterion, it is essential to test. The procedure to increase text size is available on the following page: Text size enlargement.
            Sometimes the sizing of certain blocks of text, in particular using sizes in pixels, can lead to loss of information (truncated texts), it is therefore advisable to use relative units (%, em, rem ...).

            -

            Color contrast #

            +

            Color contrast #

            The guidelines do not require the use or even prohibit the use of certain colors for texts. However, a light gray text on a white background, for example, could be difficult. It is therefore essential to check that the text color and the background color provide a sufficient level of contrast (see levels below). This can be done easily with help of tools.

            Criterion 1.4.3 of the standard details the required contrast levels.

            For standard texts (not bold):

            @@ -219,7 +219,7 @@

            Color contrast What about users ? #

            +

            What about users ? #

            The guidelines do not impose a minimum size because it assumes that it is possible to enlarge the text if necessary. In fact, users do not always adjust the size of the text to their needs, due to a lack of habit or ignorance of the possibilities offered to them. This is why it is important that the default size is sufficient to ensure reading comfort.

            The size and the color are not the only characteristics which come into play on the readability of a text, indeed the typeface or the use of text in italics can have important consequences. You will find some additional recommendations on this subject in the editorial content section .

            diff --git a/en/articles/how-to-test-android/index.html b/en/articles/how-to-test-android/index.html index 56ba35148..6fdd7cbec 100644 --- a/en/articles/how-to-test-android/index.html +++ b/en/articles/how-to-test-android/index.html @@ -186,15 +186,15 @@

            Testing the accessibility of an Android application

            -

            Presentation and configuration of accessibility options #

            -

            Presentation of the main options #

            +

            Presentation and configuration of accessibility options #

            +

            Presentation of the main options #

            • Talkback: the screen reader for all Android devices. It allows you to vocalize all the (useful) information present on the screen. It's an essential tool for blind and visually impaired people.
            • Keyboard navigation: enable this feature to use your phone with an external keyboard (usually via Bluetooth). It's useful for people who have difficulties using the touch screen due, for example, to motor impairment.
            • Voice Access: option to control a phone only with the voice. It's essential for people who cannot physically interact with the device or an external contactor.
            • Font size: increase text size, only useful with applications that manage this option.
            -

            Accessibility shortcuts setting #

            +

            Accessibility shortcuts setting #

            For greater convenience, it is necessary to install some tools from the Google Play Store:

            • Android Accessibility Suite (install TalkBack and others tools)
            • @@ -207,8 +207,8 @@

              Accessibility shortcuts setting

              Then choose how you want to access these options: either from the navigation bar or from a floating button. We advise to use the navigation bar, which is more discreet.

              -

              Getting started with accessibility options #

              -

              TalkBack #

              +

              Getting started with accessibility options #

              +

              TalkBack #

              Navigating with the screen reader is not always easy when you are starting, but a few simple basic gestures allow you to navigate within an application.

              A detailed description of these actions is available on the following page: https://a11y-guidelines.orange.com/en/mobile/android/talkback/

              By using TalkBack, you can verify that all the essential information for understanding and navigation is rendered by the screen reader, including:

              @@ -219,7 +219,7 @@

              TalkBack Keyboard navigation #

              +

              Keyboard navigation #

              It is possible to use your phone only with an external keyboard.

              1. Connect a keyboard to the phone.
              2. @@ -231,7 +231,7 @@

                Keyboard navigation
              3. Keyboard navigation also allows you to check that the navigation order is consistent.
              -

              Voice Access #

              +

              Voice Access #

              When "Voice Access" is enabled, you can say commands like:

              • "Go home "
              • @@ -241,7 +241,7 @@

                Voice Access

                Once Voice Access has been activated, say "show labels", which will display the accessible name assigned to components without a visible label. For an application to be controllable in this way, the interactive components must have a simple and consistent accessible name (in particular in the case of a link image or button image without a visible label).

                Button on a map, with no visible label, but with an accessible name "My position"

                -

                Font size #

                +

                Font size #

                1. Increase the text size from the menu Settings > Display > Font size and style

                  @@ -255,7 +255,7 @@

                  Font size

                -

                Dark mode #

                +

                Dark mode #

                As the dark mode is used more and more, so it's strongly recommended to test your application by activating 'dark mode'.

                1. Go to Settings > Display (or directly from Control Centre).
                2. diff --git a/en/articles/how-to-test-ios/index.html b/en/articles/how-to-test-ios/index.html index 18f37654b..467c8bd1b 100644 --- a/en/articles/how-to-test-ios/index.html +++ b/en/articles/how-to-test-ios/index.html @@ -186,8 +186,8 @@

                  Testing the accessibility of an iOS application

                  -

                  Presentation and configuration of accessibility options #

                  -

                  Presentation of the main options #

                  +

                  Presentation and configuration of accessibility options #

                  +

                  Presentation of the main options #

                  -

                  Accessibility shortcuts setting #

                  +

                  Accessibility shortcuts setting #

                  For greater convenience, it is recommended to add the essential tools in the accessibility shortcuts:

                -

                Dark mode #

                +

                Dark mode #

                As the dark mode is used more and more, so it's strongly recommended to test your application by activating “dark mode”.

                1. diff --git a/en/articles/rgaa-va11ydette/index.html b/en/articles/rgaa-va11ydette/index.html index ecdee3f9b..b7e886d09 100644 --- a/en/articles/rgaa-va11ydette/index.html +++ b/en/articles/rgaa-va11ydette/index.html @@ -188,7 +188,7 @@

                  News on the Va11ydette

                  The Va11ydette makes it possible to carry out audits on the WCAG reference system and to obtain a percentage of compliance.
                  A lot of changes have been made on the Va11ydette, we will give you a summary.

                  -

                  The new RGAA checklist is available #

                  +

                  The new RGAA checklist is available #

                  You've all been waiting for it, it's finally here!!!
                  The checklist based on the RGAA repository is available on the Va11ydette.

                  You can now audit a site, looking at the 106 criteria of the RGAA.
                  @@ -201,7 +201,7 @@

                  The new RGAA check

                  Start your audit on the RGAA checklist

                  -

                  Added good practice criteria to the WCAG web checklist #

                  +

                  Added good practice criteria to the WCAG web checklist #

                  New features are also present on the WCAG Web checklist.

                  Previously there were two checklists, one for making declarations and the second allowing for more in-depth audits.
                  We decided to remove the audit checklist in order to focus on a single audit grid.

                  diff --git a/en/articles/single-page-app/index.html b/en/articles/single-page-app/index.html index d2c67c4e8..5ea58165d 100644 --- a/en/articles/single-page-app/index.html +++ b/en/articles/single-page-app/index.html @@ -189,24 +189,24 @@

                  Recommendations for Single Page Applications

                  A single-page web application (SPA) is a web application in which page refresh never occurs. During navigation, only portions of the page are dynamically updated using JavaScript code.

                  SPAs have met with enthusiasm since the advent of JavaScript frameworks: Angular, React or Vue to name only the most popular. In this article, the idea is not to take sides for or against PPS. It must be recognized that used correctly, this type of framework can solve problems, especially when it is used in the design of large web applications. We will focus here on the difficulties that this can bring in terms of accessibility.

                  Warning: SPAs should never become the norm. If your need can be met with the help of a standard site you don't need to succumb to the hype. A standard website natively offers accessibility support and spares you the need to get started with a complex framework, skills training, maintenance or compatibility problems with old browsers.

                  -

                  Update page title #

                  +

                  Update page title #

                  Browsing through an SPA does not cause the browser to reload the page. However, it is important that each page has a unique title.

                  It will therefore be necessary to update the title of the page via Javascript (document.title). Refer to the documentation of the framework used to know if an implementation of this mechanism is proposed or if it must be created from scratch.

                  -

                  Notify user of page changes #

                  +

                  Notify user of page changes #

                  Screen readers used by visually impaired people inform the user automatically when a new page is loaded by the browser. In the context of an SPA, page changes do not lead to reloading by the browser. The screen reader therefore has no way of warning the user.

                  An acceptable solution is to move the focus to the first heading <h1> of the current page. This will cause it to be read by the screen reader, so the user will be warned that a new page is displayed.
                  Note that by default an <h1> tag is not focusable. To allow it to receive focus via Javascript, you must add a tabindex="-1" attribute to it.

                  -

                  Notify the user of updates inside the page #

                  +

                  Notify the user of updates inside the page #

                  If the information is dynamically updated in the page (confirmation message, loading in progress, error display, etc.). It is important to have screen readers announce these changes. Several methods are available depending on the case:

                  -

                  Move focus #

                  +

                  Move focus #

                  On a classic website, when a user clicks on a link and a new page is displayed, the focus is automatically repositioned at the top of the page (on the body). So for users who navigate using the keyboard, just use the TAB key to move around the page.

                  In a SPA, if a user clicks on a button that causes a content update, the focus is not moved (it remains on the button). More importantly, if the page change made the element that was in focus disappear, the user will no longer know where he is on the page. It can also cause vocalization issues for people who navigate using a screen reader.

                  It is therefore important to make sure to move the focus via Javascript when necessary. Likewise if a modal dialog box is displayed on the screen, the focus must be positioned in the box when it appears and then replaced on the original element (a button for example) when it disappears.

                  -

                  Use HTML 5 semantics #

                  +

                  Use HTML 5 semantics #

                  SPA are often used in web applications. The user sometimes has to deal with an interface that looks more like a native application than that of a website. It is important to ensure that the different areas are correctly identified: navigation, content, search area, etc.

                  If your application has specific areas, it is recommended to assign them a label so that they are quickly identifiable. For example using a <region> tag and an aria-label or aria-labelledby attribute.

                  
                  @@ -220,7 +220,7 @@ 

                  Use HTML 5 semantics ARIA regions or landmarks, to get more information on the use of these tags.

                  -

                  Manage browser history #

                  +

                  Manage browser history #

                  Nothing could be more annoying than exiting an application when you simply wanted to go back to the previous page using the browser's previous button. However, this is what sometimes happens in SPA.

                  The solution is to manipulate the browser history in Javascript using the History API. This allows you to store the different states of the application and return to them using the previous and next buttons of the browser.

                  Summary of good practices

                  @@ -232,7 +232,7 @@

                  Summary of good practices

                2. Use HTML 5 semantics
                3. Manage browser history (History API)
              - +
              • Page Titles and A11y in Single Page Applications (Suzanne Aitchison)
              • What we learned from user testing of accessible client-side routing techniques with Fable Tech Labs (Marcy Sutton)
              • diff --git a/en/articles/skip-links-best-practices/index.html b/en/articles/skip-links-best-practices/index.html index 0b3f2e751..0236753b8 100644 --- a/en/articles/skip-links-best-practices/index.html +++ b/en/articles/skip-links-best-practices/index.html @@ -186,8 +186,8 @@

                Skip links best practices

                - -

                What is it? #

                + +

                What is it? #

                Skip links are shortcuts that allow you to directly access a content area or avoid some areas of the page, so you can navigate faster.

                We can distinguish 3 types of skip links:

                  @@ -196,21 +196,21 @@

                  What is it? #

                  +

                  For whom? #

                  Skip links are valuable for many users:

                  • Screen reader users or people unable to use the mouse, so they only navigate with the keyboard
                  • Users who are struggling to navigate a large page: motor impaired people (fatigability or motor limitations) or people on their smartphone (this is a way to spare the user from swiping to browse the page)
                  • the visually impaired, who use or not a screen magnifier, and have trouble having a global representation of the topology of the page
                  -

                  What are the types of solutions? #

                  +

                  What are the types of solutions? #

                  1. Quick Links: The most common solution, is a series of links (usually between 1 and 6) positioned at the top of the page and embedded in the code just after the body tag. Each link points to a region, or any other important part of the page. They are, generally, defined with a font size smaller than the body text, or hidden by default and appearing only when keyboard navigation is detected or when listening to focus capture events.
                  2. Skip links: These elements are positioned just before each page part or region to skip. They can be always visible or made visible, during keyboard navigation, on focus.
                  3. “Back to top” internal navigation links: they are often pinned (CSS sticky position) at the very bottom, right side of the viewport, always visible or appearing only when we're at the end of the vertical scrolling.
                  -

                  What are the best practices? #

                  - +

                  What are the best practices? #

                  +

                  The first question to ask is: on my site, does the user need skip links?

                  The main reasons for setting up skip links:

                    @@ -219,7 +219,7 @@
                  -

                  Using a hybrid solution? #

                  +

                  Using a hybrid solution? #

                  We have seen that the quick access links can be visible or hidden by default and can be displayed according to keyboard navigation. This last option often answers aesthetic problems. Nevertheless, it removes the benefit that these links could bring to other users who do not use the keyboard (users of software magnifiers for example). One solution, which would reconcile the advantages of the two techniques, would be to position a discrete but affording button at the top of the page, to trigger on demand the opening and closing of the quick access links panel. We could also think of a horizontal bar visible at the top of the page opening and disappearing when scrolling down the page.

                  Whatever the solution, the skip links must be visible (as far as possible) and usable by everyone!

                  For any comments, suggestions, feel free to view or create an issue on our github account ) .

                  diff --git a/en/articles/test-wcag-132/index.html b/en/articles/test-wcag-132/index.html index 1634a37ba..0cc5b386c 100644 --- a/en/articles/test-wcag-132/index.html +++ b/en/articles/test-wcag-132/index.html @@ -186,18 +186,18 @@

                  How to maintain a logical sequential order (Wcag 1.3.2)

                  -

                  General explanation #

                  +

                  General explanation #

                  The purpose of WCAG 1.3.2 criterion is to ensure that, if the order of the content matters, it must be preserved regardless of how it is presented to the user. For example, if you browse with CSS disabled or when you use a screen reader.

                  The order of content is important if the order of the content cannot be changed without affecting its meaning.
                  For example, for an ordered list or a table, the order of the content is important, on the other hand for an unordered list, the reading order has no impact on the user's understanding of the content.

                  A WEB page can be composed of several independent sections having specific roles. The relative positions of a navigation section and a main page section generally do not affect the understanding of the page content. Whether the navigation is at the top or on the left of the screen, does not interfere with understanding, even if a reading order can be imposed within one of these sections.
                  There can therefore be several reading orders on a WEB page to satisfy the success criterion.

                  -

                  What you should not do #

                  -

                  Use white space to format plain text #

                  +

                  What you should not do #

                  +

                  Use white space to format plain text #

                  When presenting content, it is important not to use space characters, such as spaces, tabs, line feeds or carriage returns.
                  In some cases, these characters are used to format tables, or reproduce columns of data in textual content. This method is prohibited because assistive technologies will not be presented with the information in a logical reading order, so the information returned to some users will be incomprehensible.

                  Below are two examples that are invalid and therefore not understandable with screen readers.

                  -

                  Example of a blank character to format a tables #

                  +

                  Example of a blank character to format a tables #

                   
                   Working hours with Classroom
                  @@ -216,7 +216,7 @@ 

                  Example of a blank char

                  Note that the presentation above is a purely a visual formatting, but no semantic relationship can represent tabular relationships.
                  Assistive technologies will read the content as it appears in the code, therefore, in an illogical and incomprehensible order. Here, the solution would be to use a table or present the information in a linear maner.

                  -

                  Example of a blank character to separate content into two columns #

                  +

                  Example of a blank character to separate content into two columns #

                  Digital accessibility aims to make possible      it is not a question of multiplying
                  access to digital information whatever       media, but from
                  @@ -227,11 +227,11 @@

                  Examp digital television or mobile phones.    

                  The paragraph above does not conform, space characters are used to separate the text into two columns. Assistive technologies will read the text line by line which would be an illogical reading order.

                  -

                  Use a layout table #

                  +

                  Use a layout table #

                  Although WCAG does not prohibit the use of layout tables, it is recommended to use layout in CSS in order to maintain the semantic reading of the content. If a layout table is used, it is important that the content makes sense when linearized.

                  Tables present content horizontally and vertically, however an assistive technology reads this content in a linear way, the table is read from top to bottom reading the entire row before moving on to the next.

                  Therefore, you have to be careful when using a layout table, you have to check that the content is understandable with a screen reader.

                  -

                  Example of an invalid table #

                  +

                  Example of an invalid table #

    @@ -250,7 +250,7 @@

    Example of an invalid table #

    +

    Use CSS to position information #

    To position content in a reading order, it is recommended to use structural markup, rather than CSS positioning properties. The latter can lead to errors, as the content can be displayed/interpreted in a different order than it is in the source code.

    So, if the reading order is important, be careful, when using CSS Flexbox, grid and position, not to change the visual order of the content compared to its position in the code:

    If a user disables CSS, or uses a screen reader, the rendering of information will no longer be in the correct order.

    -

    Example of a position menu in CSS #

    +

    Example of a position menu in CSS #

    The layout below was created with CSS, if you disable the CSS, you will notice that the reading direction will be different than the one displayed.

    Sports @@ -270,7 +270,7 @@

    Example of a position menu in CSS Clothes Accessories

    -

    Example of a tab where the content is positioned before #

    +

    Example of a tab where the content is positioned before #

    In the example below, tabs will be displayed with content that will be positioned with flexboxes.

    diff --git a/en/articles/watch-april-may-2022/index.html b/en/articles/watch-april-may-2022/index.html index 6fad997f5..f8203beed 100644 --- a/en/articles/watch-april-may-2022/index.html +++ b/en/articles/watch-april-may-2022/index.html @@ -185,14 +185,14 @@

    Digital accessibility watch April-May 2022

  • and another update on WCAG 2.2 and 3.0: https://www.linkedin.com/pulse/wcag-22-3-status-updates-rachael-bradley-montgomery/
  • and a last one: https://uxdesign.cc/wcag-2-2-is-delayed-again-and-im-ok-with-that-bd3066e56985
  • -

    accessibility in laws and standards #

    +

    accessibility in laws and standards #

    -

    Feedback and accessibility #

    +

    Feedback and accessibility #

    -

    Accessibility Strategy #

    +

    Accessibility Strategy #

    -

    Test accessibility #

    +

    Test accessibility #

    -

    Technical points in accessibility #

    +

    Technical points in accessibility #

    -

    Mobile app, mobile web #

    +

    Mobile app, mobile web #

    -

    Ergonomics, UI & UX #

    +

    Ergonomics, UI & UX #

    -

    Resources #

    +

    Resources #

    -

    Others #

    +

    Others #



    -

    Content Control #

    +

    Content Control #



    -

    Language #

    +

    Language #

    diff --git a/en/web/toolbox/methods-and-test-tools/navigating-with-a-screen-reader/index.html b/en/web/toolbox/methods-and-test-tools/navigating-with-a-screen-reader/index.html index 6a9a202b6..d0465aa05 100644 --- a/en/web/toolbox/methods-and-test-tools/navigating-with-a-screen-reader/index.html +++ b/en/web/toolbox/methods-and-test-tools/navigating-with-a-screen-reader/index.html @@ -264,12 +264,12 @@

    Navigating with a screen reader

  • Jaws: commercial, available for Windows. In trial mode, you can only use it for 40 minutes, but if you restart your computer you can use it again.
  • VoiceOver: free, available for Mac. It is directly integrated into the MacOS system.
  • -

    Getting started with NVDA #

    +

    Getting started with NVDA #

    NVDA is a free screen reader available for Windows.

    -

    Installation #

    +

    Installation #

    Download the NVDA installer on the official website.

    The default voice is not very good but it is very reactive. It is not mandatory, but you can download extra voices. Then just go to preferences to change NVDA voice settings.

    -

    Configuration #

    +

    Configuration #

    At first startup, NVDA is configured to vocalize whatever the mouse pointer is over. This mode is used by visually-impaired people who have difficulties reading the text displayed on the screen, for example. It is recommended to disable this option if you use NVDA to test accessibility on your pages.

    1. @@ -279,7 +279,7 @@

      Configuration Navigating web pages #

      +

      The main useful shortcuts to test navigation in a web page using NVDA are:

      Also note that NVDA has a speech viewer (Tools > Speech viewer), it displays everything that is vocalized.

      -

      Getting Started with Jaws #

      +

      Getting Started with Jaws #

      Jaws is a commercial and very famous screen reader, available for Windows. It is used primarily with Internet Explorer. In trial, you can only use it 40 min, but if you restart your computer you can use it again.

      -

      Installation #

      +

      Installation #

      You can download Jaws directly from the Freedom Scientific site.

      - +

      The most useful shortcuts to test navigation in a Web page with JAWS:

      -

      Getting Started with VoiceOver #

      +

      Getting Started with VoiceOver #

      VoiceOver screen reader is only available on Mac. It requires no installation since it is integrated directly into the system.
      You can activate VoiceOver from System Preferences > Accessibility. Or directly using the shortcut Command+F5.

      - +

      When launching VoiceOver, it displays an interactive guide to learn the key shortcuts. You should have a look at it.
      But here are the main shortcuts:

    List of keyboard shortcuts
    @@ -247,7 +247,7 @@

    1. Images 2. Cadres #

    +

    2. Cadres #

    @@ -268,7 +268,7 @@

    2. Cadres 3. Couleurs #

    +

    3. Couleurs #

    @@ -297,7 +297,7 @@

    3. Couleurs 4. Multimédia #

    +

    4. Multimédia #

    @@ -378,7 +378,7 @@

    4. Multimédia

    -

    5. Tableaux #

    +

    5. Tableaux #

    @@ -427,7 +427,7 @@

    5. Tableaux 6. Liens #

    +

    6. Liens #

    @@ -460,7 +460,7 @@

    6. Liens 7. Scripts #

    +

    7. Scripts #

    @@ -513,7 +513,7 @@

    7. Scripts 8. Éléments obligatoires #

    +

    8. Éléments obligatoires #

    @@ -570,7 +570,7 @@

    8. Éléments obligatoires

    -

    9. Structuration de l’information #

    +

    9. Structuration de l’information #

    @@ -611,7 +611,7 @@

    9. Structuration de l

    -

    10. Présentation de l’information #

    +

    10. Présentation de l’information #

    @@ -708,7 +708,7 @@

    10. Présentation de l

    -

    11. Formulaires #

    +

    11. Formulaires #

    @@ -813,7 +813,7 @@

    11. Formulaires 12. Navigation #

    +

    12. Navigation #

    @@ -894,7 +894,7 @@

    12. Navigation

    -

    13. Consultation #

    +

    13. Consultation #

    @@ -1011,7 +1011,7 @@

    13. Consultation Sans correspondance #

    +

    Sans correspondance #

    diff --git a/fr/contenu-et-communication/composants-animes/index.html b/fr/contenu-et-communication/composants-animes/index.html index 0ab180ba2..9de2d00cb 100644 --- a/fr/contenu-et-communication/composants-animes/index.html +++ b/fr/contenu-et-communication/composants-animes/index.html @@ -216,14 +216,14 @@

    Accessibilité des contenus vidéos, animations et audios

    ET
  • l'interface qui permet la diffusion de ces contenus doit être accessible.
  • -

    Les vidéos, animations ou audios accessibles #

    +

    Les vidéos, animations ou audios accessibles #

    Pour qu’une vidéo ou un audio soit accessible, les éléments suivants doivent accompagner le contenu :

    • Une transcription intégrale (seule nécessité pour un fichier audio),
    • Des sous-titres,
    • Une audiodescription si besoin.
    -

    Transcription intégrale #

    +

    Transcription intégrale #

    La transcription intégrale est la solution nécessaire et suffisante pour rendre accessible un fichier audio.
    La transcription doit restituer textuellement l’ensemble des informations importantes véhiculées par le contenu, celles-ci peuvent être :

      @@ -244,33 +244,33 @@

      Transcription intégrale Sous-titres #

      +

      Sous-titres #

      Les sous-titres doivent

      • restituer l’ensemble des contenus (tout son porteur d'information : voix, coup de feu, ...) véhiculés par la bande son de la vidéo. Ils doivent être au format texte et synchronisés avec le son de la vidéo,
      • être associées à cette dernière grâce à un fichier texte indépendant (souvent un fichier .xml ou .srt) et ne doivent pas être affichés (incrustés) directement dans la vidéo.
      -

      Audiodescription #

      +

      Audiodescription #

      L’audiodescription doit

      • compléter la bande son originale. Elle n'est pas forcement nécessaire, par exemple, lorsqu'une vidéo est juste une interview, sans autre information visuelle,
      • remplacer, au format audio, l’ensemble des informations qui sont accessibles seulement par l’image (mouvements des acteurs, textes affichés, ...).
        De même, cette piste audio ne doit pas être intégrée directement dans la vidéo, mais lui être associée par l’intermédiaire d’un fichier audio indépendant (souvent un fichier .mp3).
      -

      Lecture #

      +

      Lecture #

      Lors de la lecture du contenu, vérifier :

      • Laisser la main à l'utilisateur sur la vidéo, l'animation ou l'audio (ne pas lancer automatiquement la lecture au chargement de la page),
      • Pour une vidéo ou une animation, celle-ci doit être exempte de tout élément qui flashe plus de trois fois par seconde ou ce flash doit se situer sous le seuil de flash générique et le seuil de flash rouge.
      -

      Un lecteur audio ou vidéo accessible #

      +

      Un lecteur audio ou vidéo accessible #

      Le lecteur vidéo utilisé doit permettre :

      • de prendre en charge au moins les sous-titres et l'audiodescription,
      • d'utiliser les boutons (lecture/pause, avance/recul, montrer/cacher les sous-titres, arrêt/contrôle du volume, ajouter/enlever l'audiodescription, si besoin) au clavier,
      • de modifier les paramètres d'affichage des sous-titres (à minima : la taille du texte et les couleurs du texte/fond) .
      -

      Liens utiles #

      +

      Liens utiles #

      • Article en anglais sur le site du W3C  How to make audio and video accessible
      • Article en anglais sur le site de SitePoint : 8 Steps to Creating Accessible Video
      • diff --git a/fr/contenu-et-communication/e-learning/index.html b/fr/contenu-et-communication/e-learning/index.html index a84352735..6d1759b90 100644 --- a/fr/contenu-et-communication/e-learning/index.html +++ b/fr/contenu-et-communication/e-learning/index.html @@ -239,8 +239,8 @@

        Thématiques

        Recommandations Storyline 360

        Recommandations pour la création de présentation e-learning accessible.
        Remarque : en complément les recommandations éditoriales générales (couleurs, faciliter la lecture, etc...) sont également à appliquer, mais non décrites dans cet article.

        -

        Personnaliser l’expérience utilisateur dès le début #

        -

        Fournir des instructions dès le premier diapositive #

        +

        Personnaliser l’expérience utilisateur dès le début #

        +

        Fournir des instructions dès le premier diapositive #

        Les utilisateurs doivent pouvoir connaître et anticiper les mécanismes de navigation.

        • Fournir des instructions textuelles dès le premier diapositive
        • @@ -251,7 +251,7 @@

          Fournir des instruc
          Si des raccourcis clavier sont définis, ceux-ci doivent être annoncés dès le premier diapositive.
          -

          Proposer le choix entre différents profils #

          +

          Proposer le choix entre différents profils #

          L'objectif de l’accessibilité est de proposer une seule interface utilisable par tous les utilisateurs, valides ou en situation de handicap.
          Cependant les e-learnings comportent des spécificités, tels que des serious game par exemple, qui peuvent empêcher la mise en place d’une interface sans dégradations de l’expérience pour tous les utilisateurs.
          La solution est donc de proposer le choix de profils.
          @@ -264,7 +264,7 @@

          Proposer le choix entre diff
          Dans cet exemple des Serious Games alternatifs sont proposés aux utilisateurs non-voyants.
          -

          Permettre d'utiliser les principales fonctionnalités de l'application au clavier #

          +

          Permettre d'utiliser les principales fonctionnalités de l'application au clavier #

          Il s'agit de permettre aux utilisateurs qui ne peuvent pas utiliser la souris (non-voyants, déficients moteurs, ...) d'accéder aux fonctionnalités principales de l'application depuis le clavier.

          • S’assurer que tous les éléments interactifs sont accessibles au clavier
          • @@ -276,7 +276,7 @@

            Rendre le focus visible en toute circonstance #

            +

            Rendre le focus visible en toute circonstance #

            La visualisation du focus permet aux utilisateurs clavier de se repérer dans leur parcours de navigation.

            1. Activer "Propriétés du lecteur"
            2. @@ -284,8 +284,8 @@

              Rendre le focus visible e
            3. Modifier la couleurs par défaut du focus

             

            -

            S’assurer que l’utilisateur garde le contrôle lors des interactions #

            -

            Connaitre le résultat de ses actions #

            +

            S’assurer que l’utilisateur garde le contrôle lors des interactions #

            +

            Connaitre le résultat de ses actions #

            Les résultats des quizzs notamment, doivent être perçus par tous les utilisateurs.

            • Utiliser les composants de notifications natifs de Storyline (feedback layers)
            • @@ -295,14 +295,14 @@

              Connaitre le résultat de ses acti
              Dans cet exemple, le résultat "Pas tout-à-fait... Toutes ces propositions sont exactes !" est vocalisé par une voix-off
              -

              Éviter les limites de temps #

              +

              Éviter les limites de temps #

              Tous les utilisateurs doivent pouvoir compléter ses actions sans comportement inattendu, comme un changement de diapositive par exemple.

              • Éviter les limites de temps pour compléter un exercice ou un quizz, lire un contenu
              • Si une limite de temps est essentielle à la réalisation d’un exercice, proposer une alternative (possibilité de désactiver ou modifier la limite de temps, ou proposer un exercice différent selon le profil par exemple)

              A l’inverse, il peut être utile de préciser le temps nécessaire à la consultation d’un contenu alternatif, ou la consultation de l’elearning.

              -

              Organiser les objets et les textes de manière logique #

              +

              Organiser les objets et les textes de manière logique #

              Pour tous les utilisateurs, quel que soit leur moyen de naviguer (lecteur d’écran, loupe d’écran, navigation clavier), l’ordre de lecture des composants à l'écran correspondra au sens de lecture de la langue du document (donc de gauche à droite et de haut en bas pour une interface en français par exemple).

              • D’une manière générale, s’assurer de reproduire un ordre de lecture logique (gauche à droite et de haut en bas suivant la langue utilisée)
              • @@ -330,8 +330,8 @@

                L’ordre des éléments dans le code source, va avoir un impact lors de la lecture depuis une aide technique, comme un lecteur d’écran par exemple. -

                Donner un titre à la présentation et aux diapositives #

                -

                Titre de présentation #

                +

                Donner un titre à la présentation et aux diapositives #

                +

                Titre de présentation #

                Le titre de présentation doit être explicite.
                Il permet aux utilisateurs finaux d'identifier la formation dans leur navigateur.
                Ceci est particulièrement important pour les utilisateurs de lecteurs d'écran.

                @@ -351,7 +351,7 @@

                Titre de présentation Le titre apparaît dans l'onglet du navigateur. -

                Titre de diapositive #

                +

                Titre de diapositive #

                Le titre de diapositive doit également être explicite.
                Il permet aux utilisateurs finaux de comprendre le contexte de chaque nouvelle diapositive.
                Notamment les utilisateurs de lecteurs d'écran, en effet cet élément sera vocalisé automatiquement à l'arrivée sur une nouvelle diapositive.

                @@ -360,7 +360,7 @@

                Titre de diapositive Double cliquer sur le titre de la diapositive pour le modifier. -

                Structurer le contenu avec des titres de niveaux #

                +

                Structurer le contenu avec des titres de niveaux #

                Appliquer des styles de titre sur les textes présentés comme des titres.
                Les titres de niveaux sont essentiels aux utilisateurs de lecteurs d'écran pour leur permettre de comprendre la structure du contenu et naviguer facilement au sein de celui-ci.

                @@ -368,7 +368,7 @@

                Struc
                Utiliser les styles appropriés (de Titre 1 à Titre 4).

                -

                Fournir des textes alternatifs pertinents #

                +

                Fournir des textes alternatifs pertinents #

                Le texte de remplacement est primordial pour les utilisateurs non-voyants.
                C’est ce contenu qui sera vocalisé.

                @@ -412,7 +412,7 @@

                Fournir des

                 

                -

                Masquer les images décoratives #

                +

                Masquer les images décoratives #

                Une image est considérée comme décorative lorsqu'elle n'apporte pas d’information supplémentaire à la compréhension d'un texte ou d'une fonctionnalité.

                Il est recommandé de masquer ces éléments aux utilisateurs de lecteur d'écran.

                Les bénéfices :

                @@ -439,7 +439,7 @@

                Masquer les images déc   -

                Indiquer la langue principale du document #

                +

                Indiquer la langue principale du document #

                Définir la langue d'un document permettra aux synthèses vocales d'adapter leur vocalisation par rapport à la langue du contenu.

                La procédure :

                  @@ -450,14 +450,14 @@

                  Indiquer la
                1. Cliquer sur « OK »

                 

                -

                Contenus audio ou vidéo #

                +

                Contenus audio ou vidéo #

                • Fournir une transcription aux audios et vidéos
                • Ne pas lancer l’audio ou la vidéo automatiquement
                • Si le média se lance automatiquement, s’assurer que l’utilisateur a la possibilité de l’arrêter manuellement

                 

                -

                Audios accessibles #

                +

                Audios accessibles #

                Certaines formations possèdent une vocalisation de chaque diapositive (voix off) :

                • Si la voix fournie des informations non présentes dans le contenu du diapositive, des sous-titres sont alors nécessaires.
                  @@ -470,9 +470,9 @@

                  Audios accessibles Vidéos accessibles #

                  +

                  Vidéos accessibles #

                  Consultez nos recommandations sur les contenus audio et vidéo pour en savoir plus.

                  -

                  Ressources #

                  +

                  Ressources #

                  • Designing Accessible E-Learning Using Articulate Storyline (pdf, anglais)
                  • Creating Accessible eCourses (pdf, anglais)
                  • diff --git a/fr/contenu-et-communication/e-learning/momindum/index.html b/fr/contenu-et-communication/e-learning/momindum/index.html index 5b55401fa..722a36508 100644 --- a/fr/contenu-et-communication/e-learning/momindum/index.html +++ b/fr/contenu-et-communication/e-learning/momindum/index.html @@ -244,7 +244,7 @@

                    Thématiques

                    Recommandations Momindum Maker

                    Les bonnes pratiques détaillées dans cet article s'appliquent à l'outil Momindum Maker, permettant de créer des présentations vidéos à partir d'un document Powerpoint.
                    Il est donc impératif en pré-requis d'appliquer les recommandations Powerpoint sur le document servant de base à la présentation.

                    -

                    Propriétés du projet #

                    +

                    Propriétés du projet #

                    Renseigner au minimum le titre et la langue.

                    • @@ -258,7 +258,7 @@

                      Propriétés du projet  

                      -

                      Proposer des alternatives aux pistes audios et vidéos #

                      +

                      Proposer des alternatives aux pistes audios et vidéos #

                      • Sous-titres

                        @@ -276,7 +276,7 @@

                       

                      -

                      Définir un plan #

                      +

                      Définir un plan #

                      • Le système de plan généré par Momindum est accessible.
                        @@ -287,13 +287,13 @@

                        Définir un plan  

                        -

                        Quizz #

                        +

                        Quizz #

                        Les quizz Momindum sont utilisables (voir néanmoins les remarques dans le paragraphe défauts d'accessibilités.

                        • Proposer néanmoins le résultat sous forme de texte, car l’information (bonne / mauvaise réponse) est donnée uniquement par la couleur (elle sera non perçue par les utilisateurs non-voyants ou malvoyants).

                         

                        -

                        Défauts d'accessibilités #

                        +

                        Défauts d'accessibilités #

                        Si des bonnes pratiques peuvent rendre utilisable une présentation Momindum Maker, des défauts impactants pour les utilisateurs finaux sont tout de même à relever :

                        • diff --git a/fr/contenu-et-communication/emails/index.html b/fr/contenu-et-communication/emails/index.html index 838fba61b..35f75ad41 100644 --- a/fr/contenu-et-communication/emails/index.html +++ b/fr/contenu-et-communication/emails/index.html @@ -212,7 +212,7 @@

                          Concevoir des mails accessibles à tous

                          Voici une liste de recommandations pour écrire (ou produire des templates qui permettent de générer) des messages accessibles, c’est-à-dire, compréhensibles par tous.

                          Pour compléter cette article vous pouvez également télécharger notre fiche mémo sur l'accessibilité des emails.

                          -

                          Qu’est ce qui peut poser problème d’un point de vue accessibilité ? #

                          +

                          Qu’est ce qui peut poser problème d’un point de vue accessibilité ? #

                          Principalement :

                          • Les images
                          • @@ -221,14 +221,14 @@

                            À noter #

                            +

                            À noter #

                            Si votre communication contient beaucoup d'informations et que sa mise en page nécessite d’être complexe :

                            • Créer le mail avec la méthode qui vous est la plus simple,
                            • Ajouter en pièce jointe un fichier Word accessible (ou fichier texte) contenant le même niveau d’information mais sous forme textuelle uniquement,
                            • Ajouter une alternative textuelle précisant que l'équivalent textuel est contenu dans la pièce jointe.
                            -

                            Les mails du quotidien #

                            +

                            Les mails du quotidien #

                            Pour tous vos mails du quotidien :

                            -

                            Les Pushmails / newsletters / communications automatiques #

                            +

                            Les Pushmails / newsletters / communications automatiques #

                            Plusieurs options s’offrent à vous pour créer un Pushmail accessible.

                            -

                            Création à partir d’un document Word #

                            +

                            Création à partir d’un document Word #

                            1. Créer un document Word accessible en suivant nos recommandations Word.
                            2. Utiliser l’option « Envoyer au destinataire du message ».

                            Option à ajouter la première fois via Fichier > Option > Barre d’outils accès rapide > Envoyer au destinataire du message.

                            -

                            Création à partir d’un outil de newsletter / mailing #

                            +

                            Création à partir d’un outil de newsletter / mailing #

                            Il est tout à fait possible que l’outil que vous avez choisi fournisse des gabarits nativement accessibles mais cela n’empêche pas de suivre nos recommandations générales pour le contenu éditorial.

                            Toujours vérifier :

                              @@ -266,12 +266,12 @@

                              Création à partir d
                            • Titres de niveaux,
                            • Si tableaux de présentation : ajouter le role=presentation dans la balise table.
                            -

                            Création à partir d’HTML (ou autre outil dédié) #

                            +

                            Création à partir d’HTML (ou autre outil dédié) #

                            Composer le code HTML de façon accessible en suivant les principales recommandations Web.

                            Important : compte tenu des problématiques d’interprétation des multiples clients mail, la mise en page devrait plutôt être faite via des tableaux en utilisant l’attribut role=presentation dans la balise table.

                            Afin de tester ponctuellement la prise en charge de l’HTML et du CSS dans les différents clients mails, utilisez les sites Can I email ? et Can I use in HTML emails ?.
                            Afin de tester toute votre campagne mail, utiliser le site Accessible email

                            -

                            Liens utiles #

                            +

                            Liens utiles #

                            • Fiche mémo sur l'accessibilité des emails
                            • Tuto Office mails accessibles
                            • diff --git a/fr/contenu-et-communication/excel/index.html b/fr/contenu-et-communication/excel/index.html index fcbb72992..73d9376b5 100644 --- a/fr/contenu-et-communication/excel/index.html +++ b/fr/contenu-et-communication/excel/index.html @@ -244,7 +244,7 @@

                              Thématiques

                              Créer un fichier Excel accessible

                              Créer un fichier Excel accessible nécessite de respecter plusieurs recommandations :

                              -

                              Onglet de feuille #

                              +

                              Onglet de feuille #

                              Donner un nom unique et explicite à chaque onglet de feuille de calcul (par défaut, le nom commence par "Feuil") et supprimer les feuilles vides.

                              @@ -258,9 +258,9 @@

                              Onglet de feuille Plage de données et tableau #

                              +

                              Plage de données et tableau #

                              Définir explicitement les plages de données comme un tableau et prévoir des entêtes de ligne ou de colonne.

                              -

                              Plage de données existante #

                              +

                              Plage de données existante #

                              Se placer sur la première cellule de la plage de données (la première cellule de la ligne d'entête s'il y en a une).

                              -

                              Création d'une nouvelle plage de données de type tableau #

                              +

                              Création d'une nouvelle plage de données de type tableau #

                              • Utiliser le menu "Insertion > Tableau" ; Excel crée par défaut des titres "Colonne 1" ...
                              • Remplacer les en-têtes de colonnes : "Colonne 1", "Colonne 2" par un nom approprié
                              -

                              Modification d'un tableau #

                              +

                              Modification d'un tableau #

                              • Se placer dans le tableau
                              • Menu "Création de tableau" > cocher "Ligne d'en-tête", "Première colonne" ...
                              -

                              Autres recommandations pour les tableaux #

                              +

                              Autres recommandations pour les tableaux #

                              • Évitez de laisser des cellules vides et d'insérer des images
                              • Ne pas coller un tableau Excel dans un fichier PowerPoint avec l'option de collage "image"
                              -

                              Police, accentuation et langue #

                              +

                              Police, accentuation et langue #

                              • Utiliser une police de caractères sans sérif (Arial, Calibri, Helvetica)
                              • Conserver les accents sur les lettres capitales : cocher l'option "Majuscules accentuées en français" dans le menu Fichier > Options > Vérification
                              • Vérifier l'orthographe et les majuscules accentuées via l'onglet "Révision" > Orthographe
                              -

                              Mise en forme des textes #

                              +

                              Mise en forme des textes #

                              • Aligner le texte à gauche, évitez de justifier, de centrer ou d'aligner à droite
                              • Ne pas écrire de phrase tout en majuscule et éviter l'italique
                              • Cocher "Renvoyer à la ligne automatique" sur les cellules : clic droit sur les cellules, Format de cellules, Alignement
                              -

                              Couleurs et contrastes #

                              +

                              Couleurs et contrastes #

                              • Assurer un contraste suffisant entre la couleur du texte et celle de remplissage

                                @@ -328,7 +328,7 @@

                                Couleurs et contrastes

                              -

                              Image, graphique et objet incorporé #

                              +

                              Image, graphique et objet incorporé #

                              Renseigner un texte de remplacement à toute illustration (image, forme, icône, SmartArt...), graphique ou fichier incorporé ; Sélectionner l’illustration > clic droit > Modifier le texte de remplacement.

                              La fenêtre du texte de remplacement propose 2 zones : 1 champ pour saisir le texte de remplacement, 1 case à cocher pour marquer comme décoratif.
                                @@ -337,13 +337,13 @@

                                Image, graphique et
                              • Contenu lien : rédiger un texte de remplacement qui décrit la fonction ou la destination du lien
                              • Contenu informatif complexe : rédiger un texte de remplacement indiquant l’emplacement de la description détaillée. Celle-ci doit être équivalente à l’information transmise par l’image et doit être à proximité ou accessible via un lien. Exemple : préciser où se trouvent les données d’un graphique fait à partir d’un tableau.
                              -

                              Lien hypertexte #

                              +

                              Lien hypertexte #

                              Fournir des intitulés de liens explicites. Exemple : préférer « découvrez nos offres » à « cliquer ici » ou « en savoir plus ». Aller dans Menu > Insertion > Lien hypertexte, préciser le texte à afficher, l’adresse ou URL et éventuellement une info-bulle qui s’affichera au survol.

                              Pour chaque fichier téléchargeable, indiquer le nom, le format, le poids et la langue du fichier (si différente de celle du document).

                              -

                              Enregistrement du fichier #

                              +

                              Enregistrement du fichier #

                              Enregistrer toute version partagée en étant positionné sur la première feuille du fichier Excel.

                              -

                              Conversion en PDF #

                              +

                              Conversion en PDF #

                              Il est préférable de diffuser le document Excel au format PDF :

                              • Menu Fichier > Exporter > Créer un document PDF/XPS
                              • diff --git a/fr/contenu-et-communication/excel/tester/index.html b/fr/contenu-et-communication/excel/tester/index.html index db67910e3..3c0db8c1d 100644 --- a/fr/contenu-et-communication/excel/tester/index.html +++ b/fr/contenu-et-communication/excel/tester/index.html @@ -262,7 +262,7 @@

                                Tester l'accessibilité d'un fichier Excel

                              Corriger les problèmes détectés à l’aide des solutions proposées. -

                              Détection des problèmes d'accessibilité #

                              +

                              Détection des problèmes d'accessibilité #

                              Erreurs détectées automatiquement par le correcteur d’orthographe (Fichier > Options > Vérification) et le vérificateur d’accessibilité :

    diff --git a/fr/contenu-et-communication/index.html b/fr/contenu-et-communication/index.html index f92030175..522fe396a 100644 --- a/fr/contenu-et-communication/index.html +++ b/fr/contenu-et-communication/index.html @@ -205,9 +205,9 @@

    Recommandations éditoriales générales

    -

    Introduction #

    +

    Introduction #

    Cette section présente des recommandations générales à respecter pour garantir l’accessibilité de vos contenus quel que soit le support utilisé (email, PPT, PDF, Word, etc.).

    -

    Vérifier les couleurs #

    +

    Vérifier les couleurs #

    -

    Faciliter la lecture #

    +

    Faciliter la lecture #

    • Aligner les textes à gauche (éviter de justifier).
    • Mettre une majuscule à chaque début de phrase mais éviter les phrases entières en majuscule.
    • @@ -236,9 +236,9 @@

      Faciliter la lecture Mise en page avec des tableaux #

      +

      Mise en page avec des tableaux #

      Sachant que les clients de messagerie (Outlook inclus) obligent encore parfois à utiliser une mise en page en tableaux : ajouter un role="presentation" à vos balises table afin que les synthèses vocales comprennent qu'il ne s'agit que de mise en forme.

      -

      Des tableaux de données accessibles #

      +

      Des tableaux de données accessibles #

      Afin que vos tableaux de données soient accessible, simplifiez-les au maximum dès leur conception :

      • Éviter d’imbriquer les tableaux les uns dans les autres (maximum 2 niveaux d’imbrication).
      • @@ -246,8 +246,8 @@

        Des tableaux de do
      • Assurer une lecture séquentielle (on doit pouvoir lire de gauche à droite et de haut en bas).

      Et pour l'implémentation dans une page Web par exemple, consultez notre article dédié aux tableaux de données accessibles.

      -

      Annexes #

      -

      Comment mettre des accents aux majuscules ? #

      +

      Annexes #

      +

      Comment mettre des accents aux majuscules ? #

      Pour mettre des accents sur mac, il suffit de taper la lettre désirée par exemple « E » et laisser la touche enfoncée. Un menu contextuel apparait et permet de sélectionner la lettre accentuée désirée (É, È, Ë...), à noter qu'il est également possible d'utiliser des raccourcis clavier (cf. tableau ci-dessous).

      Sur Windows, les raccourcis clavier suivants permettent d'écrire des lettres majuscule accentuées quelle que soit l'application utilisée :

    Les erreurs sont-elles détectées par Excel ?
    diff --git a/fr/contenu-et-communication/pdf/index.html b/fr/contenu-et-communication/pdf/index.html index dc1f3c4e5..a1f398984 100644 --- a/fr/contenu-et-communication/pdf/index.html +++ b/fr/contenu-et-communication/pdf/index.html @@ -210,19 +210,19 @@

    Créer des documents PDF accessibles

    -

    Introduction #

    +

    Introduction #

    Afin de rendre vos PDF compréhensibles et utilisables par tous, il faut qu'ils soient structurés en suivant ces recommandations.

    -

    Depuis Microsoft Word ou PowerPoint #

    +

    Depuis Microsoft Word ou PowerPoint #

    Retrouvez nos recommandations pour créer un PDF accessible depuis Microsoft Word et nos recommandations pour Microsoft PowerPoint.

    -

    Depuis Adobe InDesign #

    +

    Depuis Adobe InDesign #

    InDesign est un logiciel de mise en page, notamment utilisé en pré-presse pour la production de documents imprimables.
    Il est cependant tout à fait possible de configurer son fichier pour produire un PDF accessible.
    Retrouvez les recommandations Adobe inDesign sur cette notice.

    -

    Depuis Adobe Acrobat Pro #

    +

    Depuis Adobe Acrobat Pro #

    Retrouvez la fiche Adobe Acrobat Pro de AcceDe PDF.

    -

    Critères incontournables #

    +

    Critères incontournables #

    Ces critères sont utiles aux personnes créant des documents PDF sans utiliser les logiciels d’éditions cités (Microsoft Word, Adobe InDesign, Adobe Acrobat Pro, etc.), par exemple les développeurs dont les applications génèrent des documents PDF.

    -

    Structure du document #

    +

    Structure du document #

    • Le document doit contenir a minima un titre de document et une langue par défaut (les changements de langues seront indiqués dans le document).

      @@ -246,20 +246,20 @@

      Structure du document

    - +
    • L’ordre de lecture restitué par un outil d’assistance, ainsi que l’ordre de la navigation clavier (par tabulation) reflètent la structure du document.
    • La navigation au clavier doit être possible dans l’ensemble du document sans blocage (empêcher les "pièges" clavier).
      Voir les critères WCAG associés PDF3, G21.
    -

    Images #

    +

    Images #

    • Les images comportant une information ont une alternative textuelle appropriée.
    • Les documents scannés sont convertis correctement en texte par reconnaissance optique des caractères (OCR).
    • Les images décoratives sont cachées.

    Voir les critères WCAG associés PDF1, PDF4, PDF7.

    -

    Tableaux #

    +

    Tableaux #

    • Un tableau de données doit être structuré par un « tag » (balise) table contenant au moins une ligne.
    • Les en-têtes de tableaux sont utilisées de manière appropriée.
    • @@ -267,13 +267,13 @@

      Tableaux PDF6.

      -

      Liens #

      +

      Liens #

      Les intitulés de liens sont explicites ou les liens possèdent une alternative explicite.

      Voir les critères WCAG associés PDF11, PDF13.

      -

      Listes #

      +

      Listes #

      Les listes utilisent les « tags » (balises) appropriés (exemples : L, LI, Lbl et LBody).

      Voir le critère WCAG associé PDF21.

      -

      Formulaires #

      +

      Formulaires #

      Voir les critères WCAG associés PDF5, PDF10, PDF12, PDF15, PDF22.

      -

      Couleurs #

      +

      Couleurs #

      S’assurer que la couleur n’est pas le seul moyen utilisé pour communiquer l’information.

      Assurer un niveau de contraste suffisant entre la couleur du texte et celle de l’arrière-plan. Ceci est valable pour vos textes mais aussi pour les icônes, boutons et autres éléments graphiques porteurs d'information. Le contraste peut être vérifié à l’aide de l’outil Colour Contrast Analyser par exemple :

      • 4.5:1 pour du texte de taille normale.
      • 3:1 pour du texte de grande taille et les composants d'interface ou éléments graphiques porteurs d'informations.
      -

      Tester l’accessibilité d’un document PDF #

      +

      Tester l’accessibilité d’un document PDF #

      Enfin, vous pouvez demander à télécharger le PDF Validator de CommonLook ou encore installer PDF Accessibility Checker (PAC).
      Ces logiciels permettent l’exécution de tests automatiques sur un document PDF et la détection de problèmes d’accessibilité :

        diff --git a/fr/contenu-et-communication/powerpoint/index.html b/fr/contenu-et-communication/powerpoint/index.html index 14c6f3f70..245c4d057 100644 --- a/fr/contenu-et-communication/powerpoint/index.html +++ b/fr/contenu-et-communication/powerpoint/index.html @@ -244,7 +244,7 @@

        Thématiques

        Créer des présentations PowerPoint accessibles

        Produire une présentation PowerPoint accessible nécessite de respecter ces différentes recommandations :

        -

        Masques de diapositive #

        +

        Masques de diapositive #

        Définir des masques de diapositives est la première chose à faire et une condition sine qua none pour créer une présentation homogène et accessible.

        Consultez nos recommandations sur les contenus audio et vidéo pour en savoir plus.

        -

        Convertir une présentation PowerPoint en fichier PDF #

        +

        Convertir une présentation PowerPoint en fichier PDF #

        Après avoir vérifié l'accessibilité de votre présentation (voir la rubrique Tester l'accessibilité d'une présentation PowerPoint), vous pouvez convertir la présentation en PDF : Fichier > Enregistrer sous et de sélectionner le type de fichier PDF.
        Cocher la case « Balises de structure de document pour l'accessibilité ».

         

        -

        Conseils pour une présentation orale #

        +

        Conseils pour une présentation orale #

        Exprimer oralement tout ce qui est transmis visuellement. Vous pouvez activer le sous-titrage dans « Sous-titre en direct » dans le menu Diaporama. Si besoin, prévoir un système de vélotypie(méthode de transcription en temps réel) et/ou une interprétation des signes.

        Remarque : pour les présentations de plus de 50 diapositives, il faut conseiller aux lecteurs de modifier le paramètre suivant dans Adobe :
        Édition > Préférences > Lecture > Option de lecteur d’écran : « Lire l’intégralité du document »

         

        Pour vérifier l’accessibilité d’un document PDF, consultez la rubrique PDF accessible de notre site.

        -

        Ressources #

        +

        Ressources #

        • Créer des documents bureautiques accessibles, DINSIC (français).
        • Accessibilité PowerPoint, WebAIM (anglais).
        • diff --git a/fr/contenu-et-communication/powerpoint/tester/index.html b/fr/contenu-et-communication/powerpoint/tester/index.html index dde1512d2..e64c1b28d 100644 --- a/fr/contenu-et-communication/powerpoint/tester/index.html +++ b/fr/contenu-et-communication/powerpoint/tester/index.html @@ -255,7 +255,7 @@

          Comment tester l'accessibilité d'une présentation PowerPoint

        • La vérification de contrastes
        • La vérification vocale
        • -

          Tests automatiques #

          +

          Tests automatiques #

          Vous pouvez commencer vos tests avec l’outil de vérification de l’accessibilité de Microsoft Office.
          Menu > Révision > Vérifier l’accessibilité

          @@ -263,7 +263,7 @@

          Tests automatiques

          Il est important de vérifier cet ordre directement dans les masques des diapositives.

          -

          Détection des problèmes d'accessibilité #

          +

          Détection des problèmes d'accessibilité #

          Erreurs détectées automatiquement par le correcteur d’orthographe (Fichier > Options > Vérification) et le vérificateur d’accessibilité:

    @@ -322,14 +322,14 @@

    Détection des

    -

    Vérifications des contrastes de couleurs #

    +

    Vérifications des contrastes de couleurs #

    Le logiciel Colour Contrast Analyser indique si les contrastes de couleurs utilisés sont conformes.

    -

    Tests avec les synthèses vocales JAWS et NVDA #

    +

    Tests avec les synthèses vocales JAWS et NVDA #

    Afin de poursuivre vos vérifications, vous pouvez tester avec une synthèse vocale.
    Ces tests permettent de naviguer dans la même configuration que les personnes malvoyantes et non-voyantes.

    Apprendre la navigation vocale avec JAWS et NVDA

    -

    Autres tests manuels #

    +

    Autres tests manuels #

    Les grilles suivantes au format Excel permettant de vérifier l’accessibilité de vos documents Word et PowerPoint :

    • Grille d'évaluation PowerPoint (16 Ko)
    • diff --git a/fr/contenu-et-communication/reseaux-sociaux/index.html b/fr/contenu-et-communication/reseaux-sociaux/index.html index 2b586a2ac..a4dd76c60 100644 --- a/fr/contenu-et-communication/reseaux-sociaux/index.html +++ b/fr/contenu-et-communication/reseaux-sociaux/index.html @@ -211,27 +211,27 @@

      Communication accessible sur les réseaux sociaux

      Cette partie indique comment rendre vos contenus sur les réseaux sociaux le plus accessible possible.

      -

      Recommandations générales #

      -

      Rédaction du post #

      +

      Recommandations générales #

      +

      Rédaction du post #

      -

      Liens #

      +

      Liens #

      • Donner des intitulés aux liens qui permettent de comprendre l’action ou la destination du lien. Exemple : Eviter « Cliquez ici », préférer « Le forfait en détail… ».
      • Clarifier la destination du lien pour une photo, une vidéo ou un audio ; la préciser en ajoutant [IMAGE], [VIDEO] ou [AUDIO] au début de l’intitulé. Exemple : « [VIDEO] La dernière campagne de notre marque. ».
      -

      Hashtags #

      +

      Hashtags #

      • Mettre une majuscule au début de chaque mot (écrire en CamelCase)
        Cela facilite la lecture en aidant à distinguer les différents mots et cela permet au lecteur d’écran de différencier le nombre de mots.
        Par exemple #TousSolidaires est plus lisible que #TOUSSOLIDAIRES.
      • Placer les hashtags à la fin des posts/tweets.
      -

      Émojis #

      +

      Émojis #

      Chaque émoji a une description unique qui est transcrite de manière vocale par un lecteur d’écran

      • Utiliser les émojis avec parcimonie.
      • @@ -239,7 +239,7 @@

        Émojis Images #

        +

        Images #

        Les images doivent être accompagnées d’un texte de remplacement (cf. ci-dessous pour le mode d’emploi selon le réseau social)

        • Ajouter un texte de remplacement (une description alternative) aux images @@ -256,15 +256,15 @@

          Images

        -

        Vidéos #

        +

        Vidéos #

        Toutes les vidéos doivent avoir des sous-titres et si possible une transcription.

        • YouTube permet de générer automatiquement des sous-titres. Vous pouvez télécharger le .SRT via YouTube.
        • Pour les réseaux sociaux ne générant pas de sous-titres automatiques, il existe des outils comme MixCaptions (AppStore) ou AutoCap (GooglePlay).
        • Remarque : même si des outils peuvent générer automatiquement des sous-titres, il est souvent nécessaire de les vérifier.
        -

        Twitter #

        -

        Images #

        +

        Twitter #

        +

        Images #

        Par défaut Twitter renseigne l’alternative d’une image avec le texte « image ».
        Pour ajouter des descriptions personnalisées aux images :

          @@ -275,16 +275,16 @@

          Images

          Description détaillée sur le centre d’assistance de twitter.

          -

          Vidéos #

          +

          Vidéos #

          Si la vidéo n’a pas déjà des sous-titres, l’outil Média Studio permet d’en rajouter.

          Mode d’emploi des vidéos sur le Twitter.

          Si vous n’avez pas accès à Média Studio, utiliser un autre outil.

          -

          Messages vocaux #

          +

          Messages vocaux #

          Twitter a intégré la possibilité de tweeter des messages audio. Cette fonctionnalité est encore en bêta et disponible seulement sur IOS. Pour améliorer l’accessibilité, twitter a également rajouté des transcriptions générées automatiquement.

          Il n’est pas recommandé de les utiliser, la fonctionnalité n’est pas encore optimisée pour l’accessibilité.

          Mode d’emploi des messages vocaux sur Twitter.

          -

          Facebook #

          -

          Images #

          +

          Facebook #

          +

          Images #

          Facebook crée automatiquement une alternative textuelle aux images ajoutées ; pour personnaliser ce texte descriptif souvent inexact :

          • Ajouter l’image
          • @@ -294,7 +294,7 @@

            Images

            Mode d’emploi des images sur Facebook.

            -

            Vidéos #

            +

            Vidéos #

            Pour les vidéos sans sous-titres, Facebook propose nativement une solution pour importer des sous-titres aux vidéos.

            • Ajouter la vidéo
            • @@ -304,8 +304,8 @@

              Vidéos

              Mode d’emploi des vidéos sur Facebook.

              -

              Instagram #

              -

              Images #

              +

              Instagram #

              +

              Images #

              Instagram génère une alternative textuelle automatique. Il est possible de la modifier :

              • Prendre une photo ou télécharger une photo existante sur Instagram
              • @@ -316,7 +316,7 @@

                Images

                Mode d’emploi des images sur Instagram.

                -

                Vidéos #

                +

                Vidéos #

                Pour les vidéos sans sous-titres, Instagram permet l’ajout des sous-titres automatiques :

                • Prendre une vidéo ou télécharger une vidéo existante sur Instagram
                • @@ -326,13 +326,13 @@

                  Vidéos -

                  Stories #

                  +

                  Stories #

                  Les story Instagram ne sont pas encore très accessibles.
                  Pour communiquer des informations importantes, il est nécessaire de les reporter sur le mur personnel.

                  -

                  TikTok #

                  +

                  TikTok #

                  TikTok propose aux utilisateurs des vidéos de contenu divers et varié.
                  L’outil repose essentiellement sur la visualisation de vidéos et peut donc être inaccessible pour une personne sourde ou une personne aveugle par exemple.

                  -

                  Synthèse Vocale #

                  +

                  Synthèse Vocale #

                  La synthèse vocale convertit le texte saisi en une voix off à mesure qu’il apparaît dans la vidéo.

                  Pour rendre votre vidéo accessible, la synthèse vocale peut être ajoutée pendant l’édition de la vidéo en appuyant sur le texte ajouté puis en sélectionnant « Synthèse vocale ». Une voix synthétique lira clairement votre texte lors de la vidéo.

                  Tiktok propose aussi le sous-titrage des paroles ; c’est-à-dire que vous n’avez pas besoin de réécrire ce qu’il se passe ; cependant cette option n’est disponible qu’en anglais et en japonais pour le moment. (05/22)

                  diff --git a/fr/definition-accessibilite-numerique/index.html b/fr/definition-accessibilite-numerique/index.html index b5040c148..f91d74e15 100644 --- a/fr/definition-accessibilite-numerique/index.html +++ b/fr/definition-accessibilite-numerique/index.html @@ -157,7 +157,7 @@

                  Définition de l'accessibilité numérique

                  -

                  Qu’est ce que l’accessibilité numérique ? #

                  +

                  Qu’est ce que l’accessibilité numérique ? #

                  La puissance du Web réside dans son universalité. L’accès pour tous indépendamment du handicap est un aspect essentiel.

                  @@ -168,7 +168,7 @@

                  Qu’est ce que

                  L’accessibilité numérique vise à rendre possible l’accès à l’information numérique quelle que soit la nature du handicap des personnes et la façon dont chacun consulte l’information. Elle concerne différentes technologies comme le Web, les vidéos et les documents Word et PDF, mais également la télévision numérique ou les téléphones mobiles.

                  Il ne s’agit pas de démultiplier les supports de l’information, mais de respecter des règles fonctionnelles, graphiques, techniques et éditoriales qui permettront à tous d’accéder à l’information quels que soient leurs outils de consultation.

                  -

                  Qui est concerné par l’accessibilité numérique ? #

                  +

                  Qui est concerné par l’accessibilité numérique ? #

                  Les situations de handicap identifiées ne sont pas seulement celles que l’on voit.
                  Elles ne sont pas forcement définitives et peuvent atteindre chacun de nous à un moment de sa vie.

                   

                  diff --git a/fr/handicap-cognitif/index.html b/fr/handicap-cognitif/index.html index 931b1f490..ac2f241e0 100644 --- a/fr/handicap-cognitif/index.html +++ b/fr/handicap-cognitif/index.html @@ -163,7 +163,7 @@

                  Le handicap cognitif

                • Le handicap mental, qui est la conséquence d’une déficience intellectuelle, considérée comme une capacité plus limitée d’apprentissage et un développement intellectuel significativement inférieur à la moyenne et se traduit par des difficultés plus ou moins importantes de réflexion, de conceptualisation, de communication, de décision, etc.
                • Le handicap psychique qui est la conséquence de troubles psychiques invalidants. Comme le handicap cognitif, le handicap psychique n’implique pas de déficience intellectuelle. Il est caractérisé par une alternance d’états psychiques calmes ou tendus et par des difficultés à acquérir ou à exprimer des habiletés psychosociales, avec des déficits d’attention et des difficultés à élaborer et suivre un plan d’action. Il peut donc notamment se traduire par des angoisses, des troubles cognitifs (mémorisation, attention, capacités d’organisation, d’anticipation, adaptation au contexte de la situation) et des difficultés dans la relation à autrui et la communication.
                -

                Les troubles DYS #

                +

                Les troubles DYS #

                Les troubles DYS sont des troubles neurologiques durables qui vont affecter une fonction cognitive particulière comme la lecture, le geste, le calcul… Il ne s’agit pas d’une déficience intellectuelle, mais d’un mode de raisonnement différent.
                Les troubles DYS rassemblent différents type de troubles :

                  @@ -174,7 +174,7 @@

                  Les troubles DYS Exemples d’obstacles rencontrés par un internaute dyslexique #

                  +

                  Exemples d’obstacles rencontrés par un internaute dyslexique #

                  • des pages surchargées d’informations
                  • une mise en page non linéaire
                  • diff --git a/fr/index.html b/fr/index.html index 0a2c0d8dd..44a0be0bd 100644 --- a/fr/index.html +++ b/fr/index.html @@ -141,7 +141,7 @@

                    Accessibilité Numérique Orange

                    -

                    En quelques mots #

                    +

                    En quelques mots #

                    Recommandations, méthodes, ressources et outils proposés par EASE, E-Accessibility Solutions for Everyone, le centre de compétences groupe d'Orange sur l'accessibilité numérique.

                    Nous proposons des formations, accompagnons les projets, publions des ressources pour les parties prenantes du numérique et réalisons des audits de conformité.
                    Notre expertise couvre les sites Web (e-commerce, e-learning, applications métier, Intranet...), les applications mobile, les documents bureautiques, les réseaux sociaux d'entreprise, les courriels, les progiciels...

                    diff --git a/fr/methode-tests-utilisateur/index.html b/fr/methode-tests-utilisateur/index.html index 9629b69e9..e9860cbe8 100644 --- a/fr/methode-tests-utilisateur/index.html +++ b/fr/methode-tests-utilisateur/index.html @@ -157,7 +157,7 @@

                    Recommandations accessibilité numérique Orange

                    -

                    Méthode de test d’accessibilité avec des d’utilisateurs #

                    +

                    Méthode de test d’accessibilité avec des d’utilisateurs #

                    Pour évaluer l’accessibilité d’un site ou d’une application, l’expert réalise un audit. Il inspecte ainsi, manuellement et à l’aide d’outils, le code et les pages clés afin de vérifier leur conformité aux recommandations en vigueur (WCAG 2.1 niveau AA).

                    Pour compléter son audit, l’expert peut réaliser des tests auprès d’utilisateurs reconnus travailleurs handicapés.

                    En ergonomie « Le test utilisateur est la méthode phare pour évaluer l’expérience utilisateur d’un système dans un processus itératif. Il consiste à mettre en situation l’utilisateur afin d’observer ses comportements, ses réactions et sa performance dans la réalisation de tâches prédéfinies. Les données recueillies donnent de précieuses informations sur les forces et les faiblesses du système évalué, ainsi que sur l’expérience vécue par les utilisateurs cibles. » (Lallemand & Gronier, 2016).

                    diff --git a/fr/mobile/android/audit-wcag/index.html b/fr/mobile/android/audit-wcag/index.html index bff4e12ec..38a90d2bf 100644 --- a/fr/mobile/android/audit-wcag/index.html +++ b/fr/mobile/android/audit-wcag/index.html @@ -195,7 +195,7 @@

                    Android - Audit WCAG

                    L’audit WCAG a pour objectif de calculer les taux de conformité mentionnés sur les déclarations d’accessibilité des applications Orange.

                    Orange a mis en place une grille de questions nommée la va11ydette. Cette grille reprend les 50 critères du standard WCAG version 2.1 de niveau A et AA en 54 questions. Chaque question permet de valider ou d’invalider un ou plusieurs critères, un critère peut être traité par une ou plusieurs questions.

                    La grille calcule un taux de conformité par écran audité : ce taux est égal à la somme des critères conformes divisée par le nombre de critères applicables. Elle calcule aussi le taux moyen de conformité qui correspond à la moyenne des taux de conformité de chaque écran de l’échantillon.

                    -

                    Accéder à la va11ydette #

                    +

                    Accéder à la va11ydette #

                    Le lien ci-dessous entraine l'ouverture de la grille dans un nouvel onglet du navigateur.

                    Ouvrir la va11ydette (nouvelle fenêtre)

                    diff --git a/fr/mobile/android/conception/entetes/index.html b/fr/mobile/android/conception/entetes/index.html index e746f527e..4de0f18e4 100644 --- a/fr/mobile/android/conception/entetes/index.html +++ b/fr/mobile/android/conception/entetes/index.html @@ -272,7 +272,7 @@

                    Thématiques

                    Android designer - Entêtes

                    -

                    Avoir un titre d'écran pertinent et unique #

                    +

                    Avoir un titre d'écran pertinent et unique #

                    Cible : tout le monde
                    Quand : dès la conception et à la rédaction du contenu.

                    Description :

                    diff --git a/fr/mobile/android/conception/formulaire/index.html b/fr/mobile/android/conception/formulaire/index.html index dc351b262..6efecc8b6 100644 --- a/fr/mobile/android/conception/formulaire/index.html +++ b/fr/mobile/android/conception/formulaire/index.html @@ -272,7 +272,7 @@

                    Thématiques

                    Android designer - Écran de saisie

                    -

                    Avoir des champs de saisie explicites #

                    +

                    Avoir des champs de saisie explicites #

                    Cible : tout le monde et en particulier les personnes déficientes visuelles.
                    Quand : lors de la conception et lors du développement.

                    Description :

                    @@ -295,7 +295,7 @@

                    Avoir des champs
                  • 3.3.2 Labels or instructions
                  • 1.3.5 Identify input purpose
                  -

                  Identifier les erreurs de saisie #

                  +

                  Identifier les erreurs de saisie #

                  Cible : tout le monde et en particulier les personnes déficientes visuelles.
                  Quand : lors de la conception et lors du développement.

                  Description :

                  diff --git a/fr/mobile/android/conception/multimedia/index.html b/fr/mobile/android/conception/multimedia/index.html index caf8058c9..916dbda1d 100644 --- a/fr/mobile/android/conception/multimedia/index.html +++ b/fr/mobile/android/conception/multimedia/index.html @@ -272,7 +272,7 @@

                  Thématiques

                  Android designer - Multimédia

                  -

                  Contrôler le contenu multimédia #

                  +

                  Contrôler le contenu multimédia #

                  Cible : tout le monde et en particulier les personnes déficientes visuelles et cognitives.
                  Quand : lors de la conception et lors du développement.

                  Description :

                  @@ -290,7 +290,7 @@

                  Contrôler le contenu
                • 1.4.2 Audio Control
                • 2.2.2 Pause, Stop, Hide
                -

                Transcrire le contenu audio ou vidéo #

                +

                Transcrire le contenu audio ou vidéo #

                Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives et auditives et celles qui maîtrisent mal le français.
                Quand : lors de la conception et lors du développement.

                Description :

                @@ -309,7 +309,7 @@

                Transcrire le con
              • 1.2.4 Captions (Live)
              • 1.2.5 Audio Description (Prerecorded)
              -

              Eviter le contenu à risque épileptique #

              +

              Eviter le contenu à risque épileptique #

              Cible : tout le monde, et en particulier les personnes ayant des crises d'épilepsie
              Quand : lors de la conception et lors du développement.

              Description :
              diff --git a/fr/mobile/android/developpement/agrandissement/index.html b/fr/mobile/android/developpement/agrandissement/index.html index ddb97a226..c8d220e06 100644 --- a/fr/mobile/android/developpement/agrandissement/index.html +++ b/fr/mobile/android/developpement/agrandissement/index.html @@ -254,7 +254,7 @@

              Thématiques

              Android développer - Agrandissement des éléments

              -

              Agrandir les textes sans perte d'information #

              +

              Agrandir les textes sans perte d'information #

              Cible : tout le monde et en particulier les personnes déficientes visuelles.
              Quand : lors de la conception et lors du développement.

              Description :

              diff --git a/fr/mobile/android/developpement/formulaire/index.html b/fr/mobile/android/developpement/formulaire/index.html index 63fdbe714..9a1084510 100644 --- a/fr/mobile/android/developpement/formulaire/index.html +++ b/fr/mobile/android/developpement/formulaire/index.html @@ -254,7 +254,7 @@

              Thématiques

              Android développer - Écran de saisie

              -

              Avoir des champs de saisie explicites #

              +

              Avoir des champs de saisie explicites #

              Cible : tout le monde et en particulier les personnes déficientes visuelles.
              Quand : lors de la conception et lors du développement.

              Description :

              diff --git a/fr/mobile/android/developpement/navigation-focus/index.html b/fr/mobile/android/developpement/navigation-focus/index.html index 1b703a204..d6a5f0170 100644 --- a/fr/mobile/android/developpement/navigation-focus/index.html +++ b/fr/mobile/android/developpement/navigation-focus/index.html @@ -254,7 +254,7 @@

              Thématiques

              Android développer - Navigation au clavier & Switch Access

              -

              Accéder aux éléments interactifs #

              +

              Accéder aux éléments interactifs #

              Cible : tout le monde et en particulier les personnes déficientes motrices ou cognitives.
              Quand : lors de la conception et lors du développement.

              La navigation avec Switch Access ou avec clavier est très utile pour les personnes qui présentent des difficultés motrices ou cognitives. Cette navigation permet de passer d’élément interactif en élément interactif (élément sur lequel on peut effectuer une action).

              @@ -336,7 +336,7 @@

              Accéder aux élémen
            • 4.1.2 Name, Role, Value
            • 2.4.7 Focus Visible
            -

            Ordonner la navigation au clavier #

            +

            Ordonner la navigation au clavier #

            Cible : tout le monde et en particulier les personnes déficientes motrices qui utilisent un clavier pour naviguer.
            Quand : lors de la conception et lors du développement.

            Description :

            diff --git a/fr/mobile/android/developpement/navigation-vocale/index.html b/fr/mobile/android/developpement/navigation-vocale/index.html index 52c08e3a8..eead2868c 100644 --- a/fr/mobile/android/developpement/navigation-vocale/index.html +++ b/fr/mobile/android/developpement/navigation-vocale/index.html @@ -254,7 +254,7 @@

            Thématiques

            Android développer - Navigation vocale

            -

            Vocaliser les images #

            +

            Vocaliser les images #

            Cible : tout le monde et en particulier les personnes ayant des déficiences visuelles.
            Quand : dès la conception, à la rédaction du contenu et pendant le développement.

            Description :

            @@ -289,7 +289,7 @@

            Vocaliser les images 1.4.5 Images of Text



          -

          Vocaliser tous les éléments signifiants #

          +

          Vocaliser tous les éléments signifiants #

          Cible : tout le monde et en particulier les personnes déficientes visuelles.
          Quand : dès la conception, à la rédaction du contenu et pendant le développement.

          Description :
          @@ -351,7 +351,7 @@

          Vocaliser tous
        • 1.1.1 Non-text Content



        -

        Rédiger de bonnes alternatives textuelles #

        +

        Rédiger de bonnes alternatives textuelles #

        Description :
        Il est essentiel d'écrire de bonnes alternatives textuelles afin de faciliter la compréhension des utilisateurs de lecteurs d'écrans. La rédaction d'une bonne alternative dépend de ce qu'on souhaite décrire.

          @@ -360,7 +360,7 @@

          Rédiger de
        • Images : le cas des images qui est plus complexe est détaillé dans ce chapitre



        -

        Vocaliser l'état des éléments #

        +

        Vocaliser l'état des éléments #

        Cible : tout le monde et en particulier les personnes déficientes visuelles.
        Quand : lors du développement.

        Description :

        @@ -480,7 +480,7 @@

        Vocaliser l'état des él
      • 1.1.1 Non-text Content



      -

      Gérer l'ordre de lecture avec la navigation vocale #

      +

      Gérer l'ordre de lecture avec la navigation vocale #

      Cible : tout le monde et en particulier les personnes déficientes visuelles.
      Quand : dès la conception, à la rédaction du contenu et pendant le développement.

      Description :

      @@ -513,7 +513,7 @@

      Gér
    • 2.4.3 Focus Order



    -

    Vocaliser le changement de contenu #

    +

    Vocaliser le changement de contenu #

    Cible : tout le monde et en particulier les personnes déficientes visuelles.
    Quand : dès la conception, à la rédaction du contenu et pendant le développement.

    Description :

    @@ -563,7 +563,7 @@

    Vocaliser le change } } -

    Ne pas vocaliser les éléments décoratifs et cachés #

    +

    Ne pas vocaliser les éléments décoratifs et cachés #

    Cible : tout le monde et en particulier les personnes déficientes visuelles.
    Quand : dès la conception, à la rédaction du contenu et pendant le développement.

    Description :

    @@ -623,7 +623,7 @@

    Ne -

    Regrouper les éléments #

    +

    Regrouper les éléments #

    Cible : tout le monde et en particulier les personnes déficientes visuelles.
    Quand : dès la conception, à la rédaction du contenu et pendant le développement.

    Description :

    @@ -673,7 +673,7 @@

    Regrouper les éléments
  • 1.3.1 Info and Relationships
  • -

    Gérer la navigation par entêtes #

    +

    Gérer la navigation par entêtes #

    Cible : tout le monde et en particulier les personnes déficientes visuelles.
    Quand : dès la conception, à la rédaction du contenu et pendant le développement.

    Description :

    @@ -707,7 +707,7 @@

    Gérer la navigation p
  • 2.4.6 Headings and Labels
  • 1.3.1 Info and Relationships
  • -

    Masquer des éléments à l’accessibilité #

    +

    Masquer des éléments à l’accessibilité #

    Cible : tout le monde et en particulier les personnes ayant des déficiences visuelles et/ou motrices.
    Quand : dès la phase de conception et lors du développement.

    Description :

    @@ -737,7 +737,7 @@

    Masquer des él myTextView2.setImportantForAccessibility(View.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS); // KITKAT
    myTextView1.importantForAccessibility = 4 // JELLY_BEAN
    myTextView2.importantForAccessibility = View.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS // KITKAT

    -

    Détecter si TalkBack est activé #

    +

    Détecter si TalkBack est activé #

    Description :

    Sous Android, il est possible de savoir si l’API d’accessibilité est activée, et par extension de savoir si TalkBack est activé.

    Exemple :

    diff --git a/fr/mobile/android/index.html b/fr/mobile/android/index.html index 6ead6d7d4..144236e0f 100644 --- a/fr/mobile/android/index.html +++ b/fr/mobile/android/index.html @@ -187,13 +187,13 @@

    Les critères incontournables sous Android

    -

    Pour la conception #

    +

    Pour la conception #

    Ce socle de critères destiné aux applications mobiles Android Orange pose les fondations qui permettent de s’engager dans une démarche de mise en accessibilité.

    Le respect de la charte Orange pour Android, document disponible sur le site de la marque Orange est un prérequis à l’utilisation de ce socle.
    Certains points déjà présents dans la charte Orange (utilisation des couleurs notamment) n’ont pas été repris dans cette liste de critères.

    -

    Pour le développement #

    +

    Pour le développement #

    Les critères incontournables pour le développement ont pour vocation d’aider les développeurs avec les principales options d’accessibilité du SDK Android. À travers différentes catégories, ce guide explique comment utiliser les attributs et méthodes d’accessibilité et propose des liens vers la documentation officielle de Google.

    -

    Pour les tests #

    +

    Pour les tests #

    Pour vérifier le respect des critères, un certain nombre d’outils sont disponibles sous Android. Certains sont des outils dédiés au test comme l’accessibility scanner, d’autres sont les outils permettant de palier à des déficiences comme Talkback.

    diff --git a/fr/mobile/android/talkback/index.html b/fr/mobile/android/talkback/index.html index bb274fa04..27ad8d029 100644 --- a/fr/mobile/android/talkback/index.html +++ b/fr/mobile/android/talkback/index.html @@ -195,7 +195,7 @@

    Guide d’utilisation de TalkBack

    TalkBack est un lecteur d’écran intégré à Android qui décrit à haute voix les éléments qui apparaissent sur l’écran du téléphone. Il est gratuit et permet à un utilisateur non- ou malvoyant, dyslexique ou illettré de pouvoir vocaliser tous les éléments visibles contenus dans la page. Un outil comme TalkBack est appelé indifféremment lecteur d’écran ou synthèse vocale, même si un lecteur d’écran est en fait un logiciel associé à une synthèse vocale.

    Lorsque TalkBack est activé, les gestes standards effectués sur l’écran tactile donnent des résultats différents. En outre, des gestes supplémentaires permettent de déplacer le focus à l’écran et de contrôler les éléments sélectionnés. TalkBack comprend des gestes de toucher et de balayage à un, deux et trois doigts. Nous décrivons ici les gestes de base pour une utilisation courante de TalkBack. À noter : TalkBack n’est considéré comme accessible qu’à partir de la version JellyBean (4.1) car on peut naviguer séquentiellement.

    Avant toute chose, commencez par mettre à jour TalkBack : page de l’application sur le PlayStore

    -

    Gestes de bases #

    +

    Gestes de bases #

    Se déplacer avec un doigt sur l’écran
    diff --git a/fr/mobile/android/test/outils-analyse/index.html b/fr/mobile/android/test/outils-analyse/index.html index ed89245dd..3d81704cd 100644 --- a/fr/mobile/android/test/outils-analyse/index.html +++ b/fr/mobile/android/test/outils-analyse/index.html @@ -243,7 +243,7 @@

    Thématiques

    Scan de l'application : les outils d'analyse

    Les outils d’analyse complètent parfaitement la première approche, afin de détecter d’autres problèmes d’accessibilité potentiels, comme ceux liés à la taille des boutons, aux contrastes des couleurs etc…

    -

    Accessibility Scanner #

    +

    Accessibility Scanner #

    Le scanner est téléchargeable sur le playstore.

    Le scanner prend des captures d’écran de la page et vérifie :

      @@ -254,7 +254,7 @@

      Accessibility Scanner Colour contrast analysor permet de faire un diagnostic plus précis.

      -

      Mode opératoire : #

      +

      Mode opératoire : #

      • Activer le scanner dans les paramètres/accessibilité/Accessibility Scanner (paramètres/accessibilité/Services installés/Accessibility Scanner avec la surcouche de Samsung). Cela affiche un “floating action button” sur l’écran.
      • Actionner le bouton sur les écrans à tester. Une capture d’écran est réalisée et la liste des corrections suggérées s’affiche.
      • @@ -264,7 +264,7 @@

        Mode opératoire :

        Le rapport ainsi généré par Accessibility Scanner une fois le bouton cliqué.

        capture d’écran présentant le rapport de l'outil Accessibility Scanner -

        Google Play - Pre Launch Report #

        +

        Google Play - Pre Launch Report #

        Proche de l’analyse effectuée par Accessibility Scanner, Google Play est en mesure de générer des rapports d’accessibilité après avoir transféré son application sur la console développeur. Celui-ci, s’appuyant sur le même Framework que l’application Accessibility Scanner, vérifie notamment 3 exigences UI au sein de l’application :

        • La zone utilisée pour les éléments interactifs : un bouton trop petit sera alors indiqué dans le rapport par exemple
        • @@ -274,7 +274,7 @@

          Google P

          Ce test étant réalisé depuis la console Google Play, cela peut être une dernière vérification faite par le Product Owner lui-même, avant de pousser en production l’application, et ainsi constater que les critères d’accessibilité ont bien été respectés.

          Exemple de rapport généré par Google Play Report :

          capture d’écran présentant un rapport d'accessibilité, sur la console développeur

          -

          aXe #

          +

          aXe #

          aXe est une application présente sur le Google Play Store et qui permet, de même que Accessibility Scanner ou que le Pre Launch Report de Google, d’afficher les problèmes d’accessibilité au sein des différents écrans de son application. Bien que redondant avec les deux outils précédents présentés dans certaines vérifications, il est recommandé de l’utiliser en complément, puisqu’il sera en mesure d’afficher des erreurs différentes d’accessibilité, et complètera donc parfaitement les premiers examens, pour avoir un compte rendu plus complet.

          L’utilisation d’aXe est très facile, puisqu’il suffit de télécharger l’application et de se laisser ensuite guider. A l’aide d’un floating buton, une analyse pourra être lancée sur l’écran de son choix, et les rapports d’erreurs seront immédiatement retranscrits au bas de l’écran.

          Exemple d'utilisation de aXe :

          @@ -282,12 +282,12 @@

          aXe

          Le rapport ainsi généré par aXe une fois le bouton cliqué.

          capture d’écran présentant le rapport de l'outil aXe -

          UI Automator View #

          +

          UI Automator View #

          UI Automator View est un outil présent dans le SDK Android, qui permet de scanner et d’analyser les composants UI d’une application Android. Cela permet ainsi de voir la hiérarchie des vues et les différentes propriétés pour chacune d’elle.
          Bien que n’étant pas un outil dédié à l’accessibilité, celui-ci peut être utilisé afin d’analyser plus en détail un problème d’accessibilité rencontré, et ainsi mieux en comprendre l’origine.

          Pour utiliser cet outil, vous avez donc besoin d’installer le SDK Android. Une fois celui-ci installé, vous devriez pouvoir trouver l’outil au chemin suivant : C:\users\username\AppData\Local\Android\sdk\tools\uiautomatorviewer.bat

          Il est ainsi possible de l’utiliser au sein d’une application présente sur son téléphone, si celui-ci a le mode développeur activé et qu’il est connecté via un câble USB à l’ordinateur sur lequel UI Automator View/ est lancé. Une fois ces conditions réunies, il suffit de cliquer sur le bouton Device Screenshot dans l’outil pour lancer l’analyse des composants UI de l’écran affiché sur le téléphone.

          -

          Outil tracé des contours #

          +

          Outil tracé des contours #

          Il est possible sous Android d’afficher les contours des différentes vues d’une application, ce qui permet de détecter les possibles problématiques liées aux dimensions des éléments, de vérifier des marges suffisantes entre divers éléments, et de vérifier que chaque zone sensible a une taille suffisante.
          Pour ce faire, il suffit de naviguer dans les paramètres, puis dans les options pour les développeurs du téléphone, et d’activer l’option « Afficher les contours » dans la catégorie « Tracé »

          Exemple d'utilisation du tracé des contours :

          @@ -295,7 +295,7 @@

          Outil tracé des contours

          Exemple d'écran avec le tracé des contours actifs

          capture d’écran présentant un écran de l'application Orange TV, en ayant le tracé des contours des différentes vues -

          Colour Contrast Analyser #

          +

          Colour Contrast Analyser #

          Les contrastes de couleurs se vérifient sur les maquettes de l’application, ou via Accessibility Scanner sur un mobile Android. Si un doute subsiste, il est possible de faire un screenshot de l’application, puis de faire une vérification sur un ordinateur Mesurer le niveau de contraste des couleurs via l'outil Colour Contrast Analyser.
          Pour les valeurs à respecter voir la section concernant les couleurs.

          These images are licensed under a Creative Commons Share Alike 2.0 license. Photo credit: openexhibits

          diff --git a/fr/mobile/android/test/test-developpeurs/index.html b/fr/mobile/android/test/test-developpeurs/index.html index bb133f7f4..bbab05df3 100644 --- a/fr/mobile/android/test/test-developpeurs/index.html +++ b/fr/mobile/android/test/test-developpeurs/index.html @@ -243,7 +243,7 @@

          Thématiques

          Tests des développeurs : analyse du code

          Cette étape permet de remonter directement des problèmes d’accessibilité pendant la phase de développement et provoque des erreurs de build de l’application, ou divers warnings. Le développeur doit ainsi les corriger directement pour pouvoir builder son application et la faire fonctionner, ce qui la rend d’office plus accessible avant même de la faire passer par des tests manuels, ou par des outils d’analyse. De plus, cela évite les possibles régressions d’accessibilité.

          -

          Lint #

          +

          Lint #

          Le développeur peut en premier lieu utiliser l’outil Lint dans Android Studio, sur son application, afin de faire une première passe sur les problèmes d’accessibilités.
          5 problèmes d’accessibilités peuvent être remontés grâce à Lint :

            @@ -255,7 +255,7 @@

            Lint -

            Tests automatisés : Espresso #

            +

            Tests automatisés : Espresso #

            Espresso est un framework permettant de tester son UI sous Android. On peut alors y intégrer le framework ATF (Accessibility Test Framework), qui va ajouter une couche de tests concernant l’accessibilité.

            Aucun test explicite n’a besoin d’être écrit. Une fois ATF intégré aux tests Expresso, les vérifications d’accessibilité se rajoutent automatiquement. ATF fonctionne cependant avec les ViewAction, c’est-à-dire qu’il va effectuer automatiquement la vérification d’accessibilité sur les interactions ViewAction mis en place dans les tests Espresso. De plus, pour activer les vérifications d’accessibilité, il faut faire appel à la fonction AccessibilityChecks.enable() dans la suite de tests.

            Voici comment l’intégrer :

            @@ -276,11 +276,11 @@

            Tests automatisés : Espres }

            C’est ainsi que, dans le cas où l’on réalise dans la suite de test un ViewAction.click() sur un bouton qui ne correspond pas à la taille requise pour un élément interactif, le test apparaitra en erreur jusqu’à ce que le problème d’accessibilité soit résolu.

            -

            Réaliser les tests automatisés d’accessibilité sur l’ensemble de l’écran #

            +

            Réaliser les tests automatisés d’accessibilité sur l’ensemble de l’écran #

            L’automatisation du test d’accessibilité selon les ViewAction peut cependant devenir limitant. C’est pourquoi, on peut indiquer lors de l’activation de ATF, que l’on souhaite faire les validations depuis la vue racine. Ainsi, toutes les vues seront testées, sans besoin d’ajouter de ViewActions. Pour ce faire, il faut remplacer AccessibilityChecks.enable() par AccessibilityChecks.enable().setRunChecksFromRootView(true)

            -

            Loguer les erreurs d’accessibilité plutôt que de provoquer l'échec des tests #

            +

            Loguer les erreurs d’accessibilité plutôt que de provoquer l'échec des tests #

            Il est possible de loguer les erreurs d’accessibilité afin de les voir apparaitre dans le logcat d’Android Studio, plutôt que de provoquer l'échec des tests Espresso, même si cela n’est pas conseillé. Cela ne doit être utilisé que dans un cadre temporaire. Pour ce faire, il faut ajouter la fonction suivante : AccessibilityChecks.enable().setThrowExceptionForErrors(false)

            -

            Créer une whitelist #

            +

            Créer une whitelist #

            Plutôt que d'afficher toutes les erreurs d’accessibilité dans le logcat, il est possible de créer une whitelist pour ne loguer que celles que l’on souhaite, tout en conservant les autres en erreur. Pour cela, il faut ajouter la fonction suivante :
            AccessibilityChecks.enable().setRunChecksFromRootView(true).setSuppressingResultMatcher(matchesView(anyOf(withId(R.id.buttonPlus))))

            Dans cet exemple, la vue ayant pour id buttonPlus ne sera pas indiquée en erreur en cas de problème d’accessibilité, mais sera affichée dans le logcat.

            diff --git a/fr/mobile/android/test/test-manuel/index.html b/fr/mobile/android/test/test-manuel/index.html index eef8ee88d..b67bbca56 100644 --- a/fr/mobile/android/test/test-manuel/index.html +++ b/fr/mobile/android/test/test-manuel/index.html @@ -243,7 +243,7 @@

            Thématiques

            Les tests manuels : mise en situation

            Les tests manuels concernent ceux que vous allez réaliser vous-même, en reproduisant la situation vécue par vos utilisateurs, et donc en utilisant leurs outils d’interaction pour votre application. Il est même préférable de faire tester l’application par de réels utilisateurs en situation de handicap si cela est possible. Plusieurs outils sont donc à utiliser, afin de prendre en compte le maximum de situations possibles :

            -

            Le lecteur d’écran TalkBack #

            +

            Le lecteur d’écran TalkBack #

            Le lecteur d’écran est un outil pour les personnes non voyantes et malvoyantes. Il a deux fonctions, la vocalisation et la navigation dans l’écran. Tous les éléments signifiants doivent être vocalisés dans un ordre logique.

            Pour l’activation et l’utilisation du lecteur, vous pourrez obtenir davantage de précision dans la section concernant TalkBack.

            La navigation peut être utilisée en :

            @@ -301,7 +301,7 @@

            Le lecteur d’écran
          • Lecture en continu : Pour utiliser la lecture de l’écran en continu, il faut ouvrir le menu contextuel général avec un balayage vers le bas puis vers la droite, puis choisir l’option (en balayant vers la droite pour la trouver dans le menu) « Lire à partir du haut de page » ou « Lire à partir de l’élément suivant », puis appuyer deux fois dessus pour sélectionner l’option. La lecture en continu démarre alors et peut-être arrêtée en appuyant sur l’écran.
          -

          Mode opératoire #

          +

          Mode opératoire #

          Parcourir l’application sur les scénarios utilisateurs et vérifier que toutes les informations sont vocalisées dans un ordre logique et compréhensible ainsi que :

          • @@ -345,16 +345,16 @@

            Mode opératoire Navigation au focus (au clavier) #

            +

            La navigation dans une application ou une page web doit être possible à l’aide d’un clavier externe (connecté au smartphone par Bluetooth ou USB), afin de reproduire le cas des personnes ne pouvant pas utiliser l’écran tactile, comme celles utilisant un joystick (sur un fauteuil roulant par exemple), ou celles étant atteintes de la maladie de parkinson. Il est important de vérifier son fonctionnement car certains développements peuvent entraîner des difficultés pour naviguer correctement dans la page.
            Pour tester la navigation au clavier, il faut connecter un clavier d’ordinateur au smartphone, soit avec un adaptateur (USB - USB C par exemple), soit, si le clavier est , bluetooth, en appairant le clavier et le téléphone. Le clavier , bluetooth a l’avantage de faciliter le débuggage.

            -

            Mode opératoire #

            +

            Mode opératoire #

            Parcourir l’application à l’aide du clavier et vérifier que :

            • toutes les fonctionnalités sont accessibles.
            • le focus reste suffisamment visible sur chaque élément recevant ce focus (éléments activables, boutons, éléments cliquables, cases à cocher…).
            -

            Liste des raccourcis clavier principaux : #

            +

            Liste des raccourcis clavier principaux : #

            • La touche TAB pour faire avancer le focus.
            • Les touches maj+TAB pour faire reculer le focus.
            • @@ -364,7 +364,7 @@

              Liste des raccourcis clavier pr

            Ce sont les mêmes touches utilisées pour tester l'accessibilité d'un site web. Mais l’usage du Tab par rapport aux flèches ainsi que l’usage de la barre espace par rapport à la touche entrée sont moins codifiés : on considère le test réussi lorsqu’au moins l’une des deux options permet de réaliser l’action.

            Il est considéré comme bloquant l’impossibilité de sortir d’une fonctionnalité ou de l’application.

            -

            Switch Access #

            +

            Switch Access #

            Switch Access est une application à destination des personnes présentant des troubles moteur. Elle permet de contrôler le téléphone en programmant des touches. Elle ne peut se substituer aux tests claviers, mais reste cependant intéressante à tester, dans le cas de la méthode two switch.

            Pour l’activer, il faut procéder comme suit :

            -

            Mode opératoire #

            +

            Mode opératoire #

            Parcourir l’application à l’aide du bouton Passer à l'option suivante (volume haut).

            Puis vérifier que :

            -

            Afficher tout les éléments interactifs #

            +

            Afficher tout les éléments interactifs #

            Pour afficher en surbrillance tous les éléments interactifs d’un écran, et ainsi réaliser une vérification rapide, il est possible d’utiliser l’option Group Selection du Switch Access.

            Pour ce faire, il faut sélectionner la méthode Group Selection en tant que Scanning Method dans les paramètres du Switch Access, et ensuite attribuer une touche pour le scan.

            Une fois au sein de son application, il suffit d’appuyer sur l’action Select (volume bas dans notre configuration) pour afficher tous les éléments interactifs de notre écran actuel et ainsi vérifier que :

            @@ -391,7 +391,7 @@

            Afficher tout les éléments int
          • Tous les éléments interactifs sont-ils bien mis en surbrillance ?
          • N’y a-t-il que des éléments interactifs en surbrillance ?
          -

          Agrandissement #

          +

          Agrandissement #

          Android propose plusieurs options d’agrandissement :

          Lire les instructions lors de l’activation des outils.

          -

          Mode opératoire : #

          +

          Mode opératoire : #

          • Positionner Taille de la police et Taille d’affichage au maximum. Parcourir l’application et noter les textes qui ne sont plus lisibles car ils ont disparu ou se chevauchent.
          • Activez l'option Agrandissement dans les paramètres d'accessibilité. Revenez à votre application et appuyez 3 fois sur l'écran (si vous avez conservé ce raccourci) pour démarrer l'affichage avec grossissement. Vérifiez que les écrans sont lisibles dans ce mode. Pincez avec 2 doigts pour régler le zoom et faites glisser 2 doigts pour vous déplacer sur l'écran. Toutes les informations sur l'écran doivent être lisibles en mode zoom.
          -

          Orientation #

          +

          Orientation #

          Il est nécessaire de vérifier l’orientation de son application, celle-ci devant fonctionner aussi bien en mode Paysage, qu’en mode portrait. Il convient donc de réaliser les tests manuels dans les deux cas, puisque contraindre l’utilisateur à un seul mode, pose des problèmes d’accessibilité.

          -

          Accessibility timeouts #

          +

          Accessibility timeouts #

          Cet outil n’est disponible qu’à partir de Android Q.

          Sur certaines applications, il arrive que l’UI change après un certain délai (par exemple la disparition des boutons de contrôles sur un lecteur vidéo après quelques secondes). Ce délai peut être adapté en fonction du besoin de chacun dans les paramètres, certains utilisateurs ayant besoin de plus de temps pour réussir à « voir » les contrôles et à interagir avec eux (que ce soit par le biais d’une assistance ou non). On peut alors faire appel à cette fonction de AccessibilityManager qui permet d’obtenir le timeout recommandé pour l’utilisateur, en fonction de ces préférences en matière d’accessibilité : public int getRecommendedTimeoutMillis (int originalTimeout, int uiContentFlags)

          Ainsi, pour tester si ce besoin d’accessibilité est bien pris en compte par l’application, il faut procéder comme suit :

          @@ -416,7 +416,7 @@

          Accessibility t
        • Choisir un délai dans les options proposées
        • Vérifier que l’application s’adapte bien au délai indiqué précédemment, pour les changements d’UI potentiellement concernés par ce délai.
        -

        Voice Access #

        +

        Voice Access #

        Voice Access est une application intégrée à Android Accessibility Suite, à destination des personnes présentant des troubles moteur. Elle permet de commander à la voix l’application à la place de l’écran tactile.

        Parmi les commandes possibles :

          @@ -443,12 +443,12 @@

          Voice Access

          Exemple d'écran avec Voice Access activé

          capture d’écran présentant un écran de l'application Orange TV, en ayant Voice Access actif, chaque élément interactif étant alors associé à un numéro -

          Sélectionner pour prononcer #

          +

          Sélectionner pour prononcer #

          Sélectionner pour prononcer est un outil intégré à Android Accessibility Suite qui permet de lire les parties de l’écran qui sont sélectionnées.

          Lorsqu’un seul élément est sélectionné, l'outil vocalise l’élément. Lorsque plusieurs éléments sont sélectionnés, il implémente un ordre logique de lecture comme Talkback mais il n’implémente pas les actions ni l’état des éléments.

          Il est utile pour les malvoyants, lorsque l’écran n’est pas lisible, pour l’apprentissage de la lecture (fonctionne comme un karaoké) ou pour l’apprentissage d’une langue étrangère.

          Il peut être utilisé dans un but de démonstration mais est redondant avec Talkback pour des tests d’accessibilité sans pouvoir le remplacer.

          -

          Simuler espace colorimétrique #

          +

          Simuler espace colorimétrique #

          Il est possible de simuler différents problèmes de vue liés à la perception des couleurs (Monochromacy, Deuteranomaly , Protanomly & Tritanomaly) directement sur son téléphone Android à l'aide d'un paramètre disponible. Celui-ci est proposé dans les options développeurs qu'il faut donc au préalable avoir déverrouillées.

          En appliquant ce paramétrage, il vous sera plus facile de détecter les problèmes relevant d'une source d'information fournie uniquement par la couleur.

          These images are licensed under a Creative Commons Share Alike 2.0 license. Photo credit: openexhibits

          diff --git a/fr/mobile/flutter/index.html b/fr/mobile/flutter/index.html index 635d6ec5e..63f011ab0 100644 --- a/fr/mobile/flutter/index.html +++ b/fr/mobile/flutter/index.html @@ -160,7 +160,7 @@

          L'accessibilité avec Flutter

          Si vous développez des applications avec Flutter, sachez qu'il est possible de produire des applications accessibles. Le framework offre notamment la gestion des lecteurs d'écran ainsi que l'agrandissement de la taille des textes.

          -

          Ressources #

          +

          Ressources #

          Pour obtenir des informations sur le sujet, commencez par la page officielle sur l'accessibilité qui ne reflète pour le moment pas toute l'étendue des possibilités.

          Vous pouvez également visionner les vidéos suivantes qui permettront d'approfondir certaines notions :

            diff --git a/fr/mobile/images/iOSdev/OrdreDeLecture_2.png b/fr/mobile/images/iOSdev/OrdreDeLecture_2.png new file mode 100644 index 000000000..7b2115185 Binary files /dev/null and b/fr/mobile/images/iOSdev/OrdreDeLecture_2.png differ diff --git a/fr/mobile/index.html b/fr/mobile/index.html index d72faf9f9..1282ceef6 100644 --- a/fr/mobile/index.html +++ b/fr/mobile/index.html @@ -160,7 +160,7 @@

            Recommandations accessibilité Orange pour les mobiles

            L’accessibilité, une nécessité pour certains, un avantage pour tous !

            -

            Définition de l’accessibilité mobile #

            +

            Définition de l’accessibilité mobile #

            C’est une application utilisable par tous

            • personnes valides.
            • @@ -173,44 +173,44 @@

              Définition de l
            • dans un contexte dégradé : mauvaise luminosité, etc...
            • avec des logiciels spécifiques de compensation du handicap.
            -

            Organisation de ce site #

            -

            Android #

            -

            1. Critères de conception #

            +

            Organisation de ce site #

            +

            Android #

            +

            1. Critères de conception #

            Liste des différents critères à respecter pour obtenir une application mobile accessible.
            Un bon moyen de prendre connaissance des éléments importants à respecter pour s’engager vers une démarche de mise en accessibilité.
             

            -

            2. Guide pour les développeurs #

            +

            2. Guide pour les développeurs #

            Section à destination des développeurs.
            Tout ce qu’il faut savoir pour coder accessible sur mobile.
             

            -

            3. Talkback #

            +

            3. Talkback #

            Guide simple pour utiliser le lecteur d’écran natif qui détaille toutes les gestuelles nécessaires pour maîtriser Talkback, outil incontournable dans une démarche d'accessibilité mobile.
             

            -

            4. Tests #

            +

            4. Tests #

            Comprend de façon synthétique les tests à mettre en oeuvre pour s'assurer que les recommandations android sont bien prises en compte avant mise en production de l'application.
             

            -

            iOS #

            -

            1. Critères de conception #

            +

            iOS #

            +

            1. Critères de conception #

            Liste des différents critères à respecter pour obtenir une application mobile accessible.

            Un bon moyen de prendre connaissance des éléments importants à respecter pour s’engager vers une démarche de mise en accessibilité.


            -

            2. Guide pour les développeurs #

            +

            2. Guide pour les développeurs #

            Section à destination des développeurs.

            Tout ce qu’il faut savoir pour coder accessible sur mobile.


            -

            3. VoiceOver #

            +

            3. VoiceOver #

            Guide simple pour utiliser le lecteur d’écran natif qui détaille toutes les gestuelles nécessaires pour maîtriser VoiceOver, outil incontournable dans une démarche d'accessibilité mobile.


            -

            4. WWDC #

            +

            4. WWDC #

            Section qui détaille des présentations Apple faites au World Wide Developers Conference ayant un impact fort dans la démarche d'accessibilité mobile.


            -

            5. Tests #

            +

            5. Tests #

            Comprend de façon synthétique les tests à mettre en oeuvre pour s'assurer que les recommandations iOS sont bien prises en compte avant mise en production de l'application.


            -

            Démonstrateur mDAN #

            +

            Démonstrateur mDAN #

            Présentation de l’application mDAN, le démonstrateur d’accessibilité numérique pour mobile.


            -

            Liens utiles #

            +

            Liens utiles #

            Quelques liens utiles qui pourront compléter les explications de ce site.

            diff --git a/fr/mobile/ios/audit-wcag/index.html b/fr/mobile/ios/audit-wcag/index.html index 876e5840a..29aeebe49 100644 --- a/fr/mobile/ios/audit-wcag/index.html +++ b/fr/mobile/ios/audit-wcag/index.html @@ -199,7 +199,7 @@

            Audit WCAG

            L’audit WCAG a pour objectif de calculer les taux de conformité mentionnés sur les déclarations d’accessibilité des applications Orange.

            Orange a mis en place une grille de questions nommée la Va11ydette. Cette grille reprend les 50 critères du standard WCAG version 2.1 de niveau A et AA en 52 questions. Chaque question permet de valider ou d’invalider un ou plusieurs critères, un critère peut être traité par une ou plusieurs questions.

            La grille calcule un taux de conformité par écran audité : ce taux est égal à la somme des critères conformes divisée par le nombre de critères applicables. Elle calcule aussi le taux moyen de conformité qui correspond à la moyenne des taux de conformité de chaque écran de l’échantillon.

            -

            Accéder à la va11ydette #

            +

            Accéder à la va11ydette #

            Le lien ci-dessous entraine l'ouverture de la grille dans un nouvel onglet du navigateur.

            Ouvrir la va11ydette (nouvelle fenêtre)

            diff --git a/fr/mobile/ios/conception/index.html b/fr/mobile/ios/conception/index.html index 2b38d9758..71fa63f8a 100644 --- a/fr/mobile/ios/conception/index.html +++ b/fr/mobile/ios/conception/index.html @@ -212,7 +212,7 @@

            Les critères de conception iOS


            Chacun de ces critères est présenté en expliquant pour qui il est important, quand on peut le mettre en place, pourquoi il est important et la règle d’accessibilité qui en découle.

            When designing your app, keep text size, weight, and layout in mind for clarity and readability. WWDC20 (voir la vidéo)


            -

            Images #

            +

            Images #



    -

    Couleurs #

    +

    Couleurs #

    diff --git a/fr/mobile/ios/test/index.html b/fr/mobile/ios/test/index.html index 4d14d1729..81277ec85 100644 --- a/fr/mobile/ios/test/index.html +++ b/fr/mobile/ios/test/index.html @@ -213,7 +213,7 @@

    Tester l'accessibilité d'une application iOS

    Chacune des fonctionnalités doit être vue comme un élément impactant fortement le confort de l'utilisateur, comme une brique essentielle à connotation humaine et pas juste fonctionnelle.

    Que ce soit dans la conception, la réalisation ou la vérification, chaque décision se doit d'être particulièrement empathique de façon à fournir la meilleure expérience utilisateur possible.


    -

    Pré-requis fondamentaux #

    +

    Pré-requis fondamentaux #

    1. Consacrer le temps nécessaire à la maîtrise de la gestuelle (guide d'utilisation de VoiceOver), contrôle de sélection).

      @@ -232,7 +232,7 @@

      Pré-requis fondamentaux

    -

    Environnement de travail #

    +

    Environnement de travail #

    Quatre grandes familles peuvent être dépeintes au sein de chaque projet :

    • @@ -262,7 +262,7 @@

      Environnement de travail

    -

    Évaluation fonctionnelle #

    +

    Évaluation fonctionnelle #

    La participation aux tests de cette partie ne nécessite aucune connaissance technique particulière si ce n'est savoir (dés)activer et utiliser des fonctionnalités d'accessibilité iOS.

    En plus des critères de base à respecter, il est primordial de s'assurer que des options d'accessibilité activées par un utilisateur sont parfaitement opérationnelles dans toutes les pages de l'application développée.

    Ci-dessous, quelques critères importants à tester impérativement :

    @@ -295,7 +295,7 @@

    Évaluation fonctionnelle

    Principales options d'accessibilité sur iOS : options utilisateurs, raccourcis & Siri, mode sombre, grossissement de texte, lecteur d'écran, contrôle de sélection

    -

    Dynamic Type #

    +

    Dynamic Type #

    Pour bien comprendre comment le grossissement de texte fonctionne, il est fortement recommandé de visionner l'exemple proposé dans la vidéo WWDC 2017 parfaitement résumée dans la partie WWDC de ce site.

    Afin de prendre en compte un panel conséquent de terminaux, il est conseillé de réaliser les tests sur plusieurs terminaux de taille différente avec lesquels chaque page devra être visualisée.

    Trois types de grossissement peuvent être particulièrement étudiés de façon à déterminer le comportement visuel aux extrêmes :

    @@ -390,7 +390,7 @@

    Dynamic Type VoiceOver.

    Maintenant, si le lecteur d'écran n'est pas encore implémenté sur une application déjà en diffusion publique, il est primordial d'en informer l'utilisateur dès sélection de l'icône applicatif en indiquant très clairement la situation de façon à éviter une consultation catastrophique et décevante.


    -

    Contrôle de sélection #

    +

    Contrôle de sélection #

    L'utilisation du contrôle de sélection s'articule autour du mode point et du mode élément.

    La sélection des éléments avec le mode élément fonctionne globalement bien quand les éléments proposés sont natifs et que l'application n'est pas trop compliquée graphiquement.

    @@ -432,19 +432,19 @@

    Contrôle de sélection Sur iOS 12 : activer Contrôle de sélection à partir du menu Général-Accessibilité-Contrôle de sélection


    -

    Évaluation technique #

    +

    Évaluation technique #

    Comme son nom l'indique, cette partie requiert des connaissances plus ou moins pointues selon ce que l'on souhaite vérifier.

    -

    Contraste des couleurs #

    +

    Contraste des couleurs #

    Graphiquement, le contraste des couleurs est très certainement le plus facilement vérifiable grâce à certains logiciels à installer en local par exemple (Colour Contrast Analyzer...).

    L'outil Accessibility Inspector dispose d'une fonctionnalité Color Contrast Calculator depuis Xcode 11 qui permet aussi de réaliser le même type de vérifications.

    Il est aussi très important de prendre en compte la luminosité (valeur > 125) ainsi que la différence de tonalité (valeur > 500) comme indiqué dans la section critères de conception liée aux couleurs.


    -

    Inspection de code #

    +

    Inspection de code #

    L'interface de développement Xcode fournit un outil particulièrement intéressant intitulé Accessibility Inspector.

    L'intérêt et l'utilisation de cet outil ne seront pas développés ici car ils sont très bien expliqués dans les vidéos parfaitement détaillées Audit d'une app en accessibilité et Découvrir Accessibility Inspector dont le visionnage est très fortement recommandé.


    -

    Tests liés au code #

    +

    Tests liés au code #

    De façon à assurer une stabilité temporelle au niveau du code, des tests unitaires et graphiques sont à mettre en place par les développeurs.

    Ces bonnes pratiques permettent de garantir une pérennité fonctionnelle en étant informé d'un éventuel écart introduit lors de développements ultérieurs.

    diff --git a/fr/mobile/ios/voiceover/index.html b/fr/mobile/ios/voiceover/index.html index c7d2bdea3..822e4b70a 100644 --- a/fr/mobile/ios/voiceover/index.html +++ b/fr/mobile/ios/voiceover/index.html @@ -282,7 +282,7 @@

    Guide d’utilisation de VoiceOver

    Le glissement qui consiste à réaliser le mouvement défini en gardant continuellement le contact entre le doigt et l'écran.

    Dans une première partie, nous décrirons les gestes de base liés à une utilisation courante de VoiceOver pour ensuite traiter le cas spécifique de l'iPhone X et finir avec des manipulations peu courantes mais néanmoins très utiles pour l'utilisateur avancé.



    -

    Gestes de bases #

    +

    Gestes de bases #


    • @@ -344,7 +344,7 @@

      Gestes de bases Terminal avec configuration sans bouton principal #

      +

      Terminal avec configuration sans bouton principal #

      L'arrivée sur le marché de l'iPhoneX sous iOS11 avec l'absence de bouton principal a quelque peu bouleversé la gestuelle classique dont on avait l'habitude.

      Ces nouveaux gestes de base ont donc fortement impacté les manipulations VoiceOver dont les principales sont fournies ci-dessous :

        @@ -374,7 +374,7 @@

        Term
        Mouvement : balayage avec 1 doigt à partir du haut de l'écran jusqu'à sentir l'émission d'une double vibration (environ à la moitié de l'écran).



        -

        Trucs & Astuces #

        +

        Trucs & Astuces #

        Cette partie contient des manipulations qui ne sont pas forcément toutes très connues mais qui peuvent s'avérer très utiles sur tout type de terminal :

        • diff --git a/fr/mobile/ios/voiceover/iphone-x/index.html b/fr/mobile/ios/voiceover/iphone-x/index.html index 2caf29dd9..ec33209af 100644 --- a/fr/mobile/ios/voiceover/iphone-x/index.html +++ b/fr/mobile/ios/voiceover/iphone-x/index.html @@ -238,7 +238,7 @@

          Rappels sur les gestes de base sans bouton principal





          -

          Déverrouiller l'écran #

          +

          Déverrouiller l'écran #

          Mouvement : balayage vers le haut à partir du bas de l'écran avec 1 doigt sur l'écran verrouillé.

          Résultat : déverrouillage automatique de l'écran avec la fonctionnalité faceID activée.

          La manipulation est exactement la même que précédemment mais elle s'applique ici sur un écran verrouillé.

          diff --git a/fr/mobile/ios/wwdc/2016/202/index.html b/fr/mobile/ios/wwdc/2016/202/index.html index 945d99ed7..330600601 100644 --- a/fr/mobile/ios/wwdc/2016/202/index.html +++ b/fr/mobile/ios/wwdc/2016/202/index.html @@ -287,50 +287,50 @@

          WWDC 2016 : Les nouveautés en accessibilité


        Par la suite, le fait de cliquer sur un titre permet d'ouvrir la vidéo de présentation Apple directement au moment indiqué.


        -

        MOTEUR - Switch Control (02:29) #

        +

        MOTEUR - Switch Control (02:29) #

        Après un petit rappel sur l'utilisation iOS de cette fonctionnalité, un focus particulier est mis sur son introduction avec tvOS.




        -

        MOTEUR - Dwell Control (03:36) #

        +

        MOTEUR - Dwell Control (03:36) #

        Des appareils spécifiques connectés à l'ordinateur permettent de l'utiliser sans avoir à manipuler la souris en associant le mouvement de cette dernière à celui des yeux.

        Lorsque le curseur se stabilise, un timer est lancé à l'expiration duquel une action dédiée est déclenchée (nouveauté MacOS).




        -

        VUE - Adaptation des couleurs (04:15) #

        +

        VUE - Adaptation des couleurs (04:15) #

        Toutes les facilités déjà présentes sur iOS et MacOS pour aider au maximum les personnes ayant des problèmes de reconnaissance de couleurs ou une forte sensibilité à la lumière sont désormais aussi disponibles sur tvOS.


        -

        VUE - Taptic time (04:53) #

        +

        VUE - Taptic time (04:53) #

        WatchOS 3 introduit cette fonctionnalité qui permet via VoiceOver de mettre en oeuvre toute une série de taps spécifiques pour donner l'heure d'une façon très silencieuse et discrète.


        -

        VUE - Loupe (05:17) #

        +

        VUE - Loupe (05:17) #

        Cette nouveauté iOS 10 permet d'utiliser son appareil mobile comme une loupe en associant des fonctionnalités d'accessibilité (stabilisateur d'écran, filtres de couleurs...) mises en situation par une démonstration au sein de cette présentation.


        -

        OUÏE - TTY (06:51) #

        +

        OUÏE - TTY (06:51) #

        L'utilisation du TTY (Typewriter) qui permet de faire passer du texte sur une ligne téléphonique grâce des appareils dédiés est désormais possible sur iOS.

        Cette nouveauté iOS 10 sous forme d'implémentation software permet donc de réaliser ce type de conversation directement sur son appareil mobile sans avoir à ajouter quelque complément matériel que ce soit.


        -

        APPRENTISSAGE - Retour audio d'écriture (07:51) #

        +

        APPRENTISSAGE - Retour audio d'écriture (07:51) #

        Outre les améliorations réalisées sur Énoncer la sélection et Énoncer le contenu de l'écran dans la partie Accessibilité - Parole des réglages, un retour audio sur ce qui est tapé à l'écran par l'utilisateur a aussi été implémenté.

        Cette nouveauté iOS 10 permet à des personnes dyslexiques par exemple de vérifier directement leurs écrits qu'une démonstration au sein de cette présentation met en évidence.


        -

        Découvrir le protocole UIAccessibility (14:19) #

        +

        Découvrir le protocole UIAccessibility (14:19) #

        Petit rappel sur les fondements du protocole informel UIAccessibility qui va être utilisé dans la suite de la présentation.




        -

        accessibilityElements (18:00) #

        +

        accessibilityElements (18:00) #

        Rappel sur l'intérêt de créer ce type d'objets et le contexte au sein duquel ils évoluent.




        -

        accessibilityFrameInContainerSpace (19:02) #

        +

        accessibilityFrameInContainerSpace (19:02) #

        Nouveauté iOS 10 qui permet la gestion automatique des coordonnées d'un élément accessible dans son container.




        -

        accessibilityCustomRotors (24:19) #

        +

        accessibilityCustomRotors (24:19) #

        Nouveauté iOS 10 qui permet d'ajouter des éléments personnalisés sur le rotor natif d'un terminal.



        La mise en place programmatique de ce type de fonctionnement est aussi présentée dans la partie développement.


        -

        tvOS (31:20) #

        +

        tvOS (31:20) #

        Rappel sur l'implémentation des éléments cités en objet ainsi que sur leur intérêt avec une navigation VoiceOver au sein de l'univers tvOS.



        diff --git a/fr/mobile/ios/wwdc/2016/407/index.html b/fr/mobile/ios/wwdc/2016/407/index.html index 3d04ad575..d96e10667 100644 --- a/fr/mobile/ios/wwdc/2016/407/index.html +++ b/fr/mobile/ios/wwdc/2016/407/index.html @@ -234,17 +234,17 @@

        WWDC 2016 : Audit d'une app en accessibilité


        À la fin de cette présentation, il est très fortement recommandé de consulter les nouveautés Xcode 11 de l'outil Accessibilty Inspector de façon à connaître parfaitement la toute dernière version.


        Par la suite, le fait de cliquer sur un titre permet d'ouvrir la vidéo de présentation Apple directement au moment indiqué.


        -

        Accessibility Inspector (09:38) #

        +

        Accessibility Inspector (09:38) #

        Présentation générale de l'outil en décrivant son contenu ainsi que les différents thèmes autour desquels va s'articuler cette présentation.



        La suite va s'attacher à détailler spécifiquement les parties audit, inspection et settings.


        -

        Audit (11:21) #

        +

        Audit (11:21) #

        Explications fournies sur l'intérêt et l'utilisation de cette fonctionnalité avec une démonstration par un exemple pratique (12:22) qui permet de mettre en avant la façon de trouver une solution au problème décelé par l'outil (14:24) tout en pouvant remonter rapidement ce problème sous forme de rapport (17:07).



        Ce type d'audit automatique est très important mais un audit manuel complémentaire est indispensable car il permet d'éviter des écueils qui pourraient être dévastateurs dans l'utilisation de l'application (18:55).


        -

        Inspection (20:30) #

        +

        Inspection (20:30) #

        Seconde fonctionnalité expliquée en s'appuyant sur un exemple (21:58) qui peut permettre de déceler différents types de problèmes :

        • @@ -260,7 +260,7 @@

          (24:40), il est précisé que les composants gérés par CALayer ne sont pas traités nativement par VoiceOver.




          -

          Settings (28:33) #

          +

          Settings (28:33) #

          Dernière fonctionnalité de l'outil qui permet d'éviter des allers-retours entre l'application testée et les modifications des principaux réglages d'accessibilité qu'une démonstration met en évidence (30:25).

          diff --git a/fr/mobile/ios/wwdc/2017/215/index.html b/fr/mobile/ios/wwdc/2017/215/index.html index 5ef82173a..ea80be112 100644 --- a/fr/mobile/ios/wwdc/2017/215/index.html +++ b/fr/mobile/ios/wwdc/2017/215/index.html @@ -272,72 +272,72 @@

          WWDC 2017 : les nouveautés en accessibilité


        Par la suite, le fait de cliquer sur un titre permet d'ouvrir la vidéo de présentation Apple directement au moment indiqué.


        -

        Détection de texte dans une image (07:07) #

        +

        Détection de texte dans une image (07:07) #

        Il est désormais possible de déterminer si du texte est incrusté dans une image.



        Cette détection très basique est obtenue en réalisant un tap avec 3 doigts.
        Elle permet ainsi de vocaliser cette inscription à une personne qui ne peut initialement pas la détecter.


        -

        Amélioration de la description d'une photo (08:01) #

        +

        Amélioration de la description d'une photo (08:01) #

        La vocalisation de la description d'une photo est une nouvelle fonctionnalité de Voice Over et est obtenue par un simple tap à l'aide de 3 doigts.



        Une détection très simple du contexte, des visages et de leurs expressions est donc exposée à l'utilisateur pour qui ce type d'informations devient plus que jamais un lien fort avec son environnement.


        -

        Ecrire des infos pour SIRI (11:37) #

        +

        Ecrire des infos pour SIRI (11:37) #

        Nouveauté très utile pour les personnes ne pouvant pas utiliser SIRI vocalement ou désirant simplement effectuer des requêtes de façon discrète.

        Pour utiliser cette fonctionnalité, il faut se rendre dans la partie Accessibilité des Réglages pour rendre l'activation effective.




        -

        Accessibility Inspector : cas pratique (15:35) #

        +

        Accessibility Inspector : cas pratique (15:35) #

        Dans cette partie, l'outil Accessibility Inspector de Xcode est utilisé pour une démonstration d'audit accessibilité d'une application.

        Des exemples sont fournis sans expliquer fondamentalement les notions propres à l'outil qui sont détaillées dans la session 407 de la WWDC en 2016.


        -

        Découvrir le protocole UIAccessibility (21:14) #

        +

        Découvrir le protocole UIAccessibility (21:14) #

        Petit rappel sur les fondements du protocole informel UIAccessibility qui vont être utilisés dans la suite de la présentation.




        -

        Attributed Accessibility Properties (26:07) #

        +

        Attributed Accessibility Properties (26:07) #

        iOS 11 permet de transformer les propriétés d'accessibilité label, value et hint de base en NSAttributedString de façon à pouvoir agir sur la façon dont ils vont être vocalisés.



        Parmi les exemples fournis, on trouve la possibilité de vocaliser en langue étrangère un élément accessible bien particulier.



        L'ensemble des clés utilisables se trouve sur la documentation officielle Apple.


        -

        Accessibility Container Type (27:20) #

        +

        Accessibility Container Type (27:20) #

        Une définition de conteneur typé au niveau accessibilité est disponible en iOS 11.



        La notion de conteneur existait déjà mais rien ne permettait au lecteur d'écran de savoir ce qu'était réellement ce conteneur.

        Ce nouveau typage va donc permettre à VoiceOver de faciliter et de mieux appréhender la façon dont l'utilisateur va pouvoir naviguer au sein de ce conteneur.


        -

        Les actions personnalisées (35:43) #

        +

        Les actions personnalisées (35:43) #

        Il est possible de définir sur une vue un ensemble constitué de accessibilityCustomAction de façon à lui attribuer différentes actions possibles.



        Dès que cette vue est sélectionnée avec VoiceOver, un swipe vertical avec un doigt permet de déterminer l'action de son choix.

        La mise en place programmatique de ce type de fonctionnement est présentée dans la partie développement.


        -

        Action par défaut (37:38) #

        +

        Action par défaut (37:38) #

        Afin de limiter ou de rendre plus faciles les manipulations à réaliser par les utilsateurs de VoiceOver, il est possible de déclencher des actions appropriées dès qu'un élément est activé par un double tap.




        -

        Les valeurs continûment ajustables (38:22) #

        +

        Les valeurs continûment ajustables (38:22) #

        La modification de valeur pour des éléments tels que le slider ou le picker peut se faire de façon très fluide grâce à l'implémentation de deux fonctions :



        Dès que la vue est sélectionnée avec VoiceOver, un swipe vertical avec un doigt permet d'augmenter ou de diminuer la valeur.

        La mise en place programmatique de ce type de fonctionnement est présentée dans la partie développement.


        -

        Sélection en défilement continu (39:40) #

        +

        Sélection en défilement continu (39:40) #

        L'application d'une double pression d'un doigt accompagnée d'un maintien à l'issue sur un défilement panoramique permet de déclencher la fonctionnalité pass-through de VoiceOver.



        Cette fonctionnalité permet d'obtenir une sélection beaucoup plus précise de la valeur remontée.

        Il est donc possible de préciser à VoiceOver le focus de l'élément sélectionné grâce à l'attribut accessibilityActivationPoint de façon à indiquer finement à l'utilisateur où il se trouve au niveau du panoramique.




        -

        Défilement personnalisé (41:02) #

        +

        Défilement personnalisé (41:02) #

        Le défilement classique de pages proposé par VoiceOver se fait avec un swipe à l'aide de 3 doigts.

        Il est toutefois possible de personnaliser le résultat obtenu grâce à la méthode accessibilityScroll présente dans le protocole UIAccessibilityAction.




        -

        Drag & Drop (42:54) #

        +

        Drag & Drop (42:54) #

        Nouveauté iOS 11, le drag-and-drop présenté en accessibilité ne décrit pas la nouvelle API mais rappelle les 2 principes primordiaux autour desquels s'appuie son fonctionnement : les drag sources et les drop points.



        Leur utilisation est ensuite succinctement proposée par le biais d'un exemple.

        diff --git a/fr/mobile/ios/wwdc/2017/245/index.html b/fr/mobile/ios/wwdc/2017/245/index.html index 7f0df047b..e86d4eebd 100644 --- a/fr/mobile/ios/wwdc/2017/245/index.html +++ b/fr/mobile/ios/wwdc/2017/245/index.html @@ -254,42 +254,42 @@

        WWDC 2017 : Application du Dynamic Type


      Par la suite, le fait de cliquer sur un titre permet d'ouvrir la vidéo de présentation Apple directement au moment indiqué.


      -

      Styles de texte (06:06) #

      +

      Styles de texte (06:06) #

      Avec iOS 11, tous les styles de texte s'adaptent aux 5 tailles de texte disponibles en accessibilité ce qui n'était le cas que pour le style body auparavant.

      Dans l'Interface Builder de Xcode, il suffit d'indiquer le style souhaité dans la partie Attribute Inspector et de cocher la case Dynamic Type qui permettra d'adapter automatiquement la taille selon les réglages.



      Au niveau code, on peut obtenir exactement le même résulat.




      -

      Police personnalisée (08:17) #

      +

      Police personnalisée (08:17) #

      L'introduction de la classe UIFontMetrics en iOS 11 permet à une police personnalisée de respecter le comportement du grossissement de caractères.




      -

      Utilisation de pages web (09:25) #

      +

      Utilisation de pages web (09:25) #

      Afin d'assurer une compatibilité entre le comportement attendu sur un terminal iOS utilisant le Dynamic Type et l'affichage de pages web sur ce même type de terminal, il est possible d'indiquer le style de texte souhaité au niveau CSS.




      -

      Affichage sur plusieurs lignes (10:14) #

      +

      Affichage sur plusieurs lignes (10:14) #

      Afin d'éviter la troncature d'un texte trop long dans un label après grossissement, il est conseillé de mettre la valeur 0 dans le nombre de lignes à afficher, ce qui aura pour signification d'afficher l'ensemble des lignes.




      -

      ConstraintEqualToSystemSpacingBelow (11:31) #

      +

      ConstraintEqualToSystemSpacingBelow (11:31) #

      Dans la mise en place de contraintes graphiques entre deux éléments de type label s'appuyant sur leur 'baseline', il est préférable de ne pas mettre de valeur fixe pour éviter le chevauchement lors de grossissement de caractères.



      Une constante égale à Standard Value dans l'Interface Builder de Xcode ou une définition programmatique de la contrainte utilisant constraintEqualToSystemSpacingBelow (nouveauté iOS 11) permet de résoudre ce problème.




      -

      ScaledValue (12:56) #

      +

      ScaledValue (12:56) #

      Introduite en iOS 11, la méthode scaledValue permet de déterminer la hauteur d'un élement graphique contenant du texte selon le grossissement implémenté.



      À utiliser par exemple pour un bouton contenant du texte dont la taille est liée au Dynamic Type et dont on souhaite connaître la hauteur.


      -

      Grossissement d'éléments voisins (13:36) #

      +

      Grossissement d'éléments voisins (13:36) #

      Arrivé à un certain seuil de grossissement, des éléments verticalement voisins peuvent finir par devenir illisibles et même transformer une interface graphique initialement ergonomique en une juxtaposition grossière d'objets.

      Dans ce cas, il est recommandé de passer à un alignement horizontal lorsque le grossisement problématique est atteint.




      -

      PreferredContentSizeCategory (15:23) #

      +

      PreferredContentSizeCategory (15:23) #

      Il existe 2 familles bien distinctes qui contiennent les paliers de grossissement souhaités :

      • @@ -304,17 +304,17 @@




        -

        Table view cells (16:38) #

        +

        Table view cells (16:38) #

        L'utilisation de table view cells standards va permettre d'adapter automatiquement la disposition d'une cellule en fonction du Dynamic Type grâce au cell-sizing.



        Dans le cadre de cellules personnalisées, il faut mettre en place les contraintes pour définir le rendu souhaité et laisser le cell-sizing opérer.




        -

        Images (20:13) #

        +

        Images (20:13) #

        Le Dynamic Type permet aussi le grossissement des images à la fois sur les vues et les barres de tabulation.

        Les explications détaillées de ce point se trouvent dans la partie développement.


        -

        Exemple (24:32) #

        +

        Exemple (24:32) #

        Une application d'exemple est proposée pour répondre aux questions que se posent les développeurs face aux éventuels problèmes rencontrés dans l'implémentation du Dynamic Type (regarder l'introduction avant de lire la suite) :

        • diff --git a/fr/mobile/ios/wwdc/2018/230/index.html b/fr/mobile/ios/wwdc/2018/230/index.html index 3bdfef40c..febf92fcc 100644 --- a/fr/mobile/ios/wwdc/2018/230/index.html +++ b/fr/mobile/ios/wwdc/2018/230/index.html @@ -268,7 +268,7 @@

          WWDC 2018 : Fournir une expérience exceptionnelle en accessibilité


          Le dernier thème développe un exemple d'application particulièrement intéressant pour les développeurs qui souhaitent trouver des réponses détaillées aux problèmes d'implémentation avec VoiceOver ainsi que celles et ceux qui souhaitent découvrir comment une application doit interagir avec VoiceOver pour que le parcours utilisateur soit optimal (voir 'Rendu final de l'application avec VoiceOver optimisé').

          Par la suite, le fait de cliquer sur un titre permet d'ouvrir la vidéo de présentation Apple directement au moment indiqué.


          -

          Floutage et transparence (03:07) #

          +

          Floutage et transparence (03:07) #

          Depuis iOS 8, des classes telles que UIBlurEffect et UIVisualEffectView permettent de gérer parfaitement l'effet de flou d'une image.

          Cependant, cela peut entraîner des difficultés occulaires pour les personnes ayant des problèmes visuels.

          L'utilisateur peut alors atténuer très fortement ces effets néfastes en activant l'option d'accessibilité appropriée dans ses réglages.

          @@ -278,14 +278,14 @@




          -

          Contraste (04:38) #

          +

          Contraste (04:38) #

          Le contraste {couleur du contenu exposé par rapport à la couleur du fond d'écran} est très important et repose beaucoup sur les propriétés de la police affichée détaillées dans la partie conception de ce site.

          Il est possible d'augmenter nativement le contraste des couleurs en activant l'option d'accessibilité appropriée dans les réglages du terminal, pouvant ainsi favoriser un confort de lecture.



          Côté développement, le suivi de la modification de ce réglage se fait grâce à la valeur de isDarkerSystemColorsEnabled.




          -

          Grossissement (07:04) #

          +

          Grossissement (07:04) #

          Les quelques points concernant le Dynamic Type sont largement expliqués dans la section développement iOS et font référence à une autre présentation parfaitement détaillée dans la partie WWDC de ce site.

          Le simple fait de passer une police en gras peut nettement améliorer le rendu visuel pour certains utilisateurs sans avoir à en grossir démesurément la taille.

          Ici encore, les réglages du terminal permettent d'activer cette option d'accessibilité.

          @@ -293,43 +293,43 @@




          -

          Mouvement (08:48) #

          +

          Mouvement (08:48) #

          Certaines animations peuvent entraîner des problèmes d'équilibre voire de nausées à certaines personnes.

          Les réglages utilisateurs permettent de réduire fortement tout type d'animations natives en activant l'option d'accessibilité appropriée.



          Côté développement, le suivi de la modification de ce réglage se fait grâce à la valeur de isReduceMotionEnabled et permet d'adapter les effets de l'application aux souhaits de l'utilisateur s'ils ne sont pas automatiquement pris en compte.




          -

          UIAccessibilityElement (21:03) #

          +

          UIAccessibilityElement (21:03) #

          L'intérêt de cet élément ainsi que son implémentation sont expliqués et mis en situation au sein de l'application de démonstration.




          -

          Les valeurs continûment ajustables (21:44) #

          +

          Les valeurs continûment ajustables (21:44) #

          Cette fonctionnalité implémentable par définition de trait spécifique est présentée ici de façon à fluidifier la sélection d'éléments dans une CollectionView.



          Un aperçu différent de cette utilisation a déjà été développé dans une autre vidéo détaillée de la partie WWDC de ce site.


          -

          Les actions personnalisées (23:49) #

          +

          Les actions personnalisées (23:49) #

          Sur une unique sélection, il est possible de regrouper un ensemble d'actions proposées sur différents éléments graphiques.



          Les explications fournies ici sont aussi développées dans une autre vidéo détaillée de la partie WWDC de ce site.


          -

          Élément au premier plan (25:02) #

          +

          Élément au premier plan (25:02) #

          Lorsqu'une vue est simplement présentée comme étant "en haut" de la hiérarchie des vues, VoiceOver ne sait pas nativement qu'il ne faut pas traiter les éléments présents en fond d'écran.

          La solution consiste à modifier accessibilityViewIsModal de façon à ce que VoiceOver n'analyse que les éléments de la vue mise en avant.



          Une explication de l'implémentation d'une vue modale est détaillée dans la partie développeur de ce site.


          -

          Notifications (25:13) #

          +

          Notifications (25:13) #

          Petit rappel pour notifier les utilisateurs de modifications sur l'écran.



          Des explications plus détaillées sur ce point sont fournies dans la partie développeur de ce site.


          -

          Exemple #

          +

          Exemple #

          Un exemple d'application est proposé pour répondre aux questions que se posent les développeurs face aux éventuels problèmes rencontrés dans la mise en oeuvre de l'accessibilité avec VoiceOver.

          La présentation de l'exemple ainsi que le rendu VoiceOver non optimisé sont absolument à visionner afin de mieux comprendre la logique des solutions apportées par tous les éléments exposés précédemment.


          -

          Comment rendre un carrousel parfaitement interprétable par VoiceOver ? (25:53) #

          +

          Comment rendre un carrousel parfaitement interprétable par VoiceOver ? (25:53) #

          • Création d'un élement accessible pour définir le carrousel. (26:11)

            @@ -354,7 +354,7 @@

            Comment synchroniser la mise à jour de données avec l'élément du carrousel sélectioné ? (30:53) #

            +

            Comment synchroniser la mise à jour de données avec l'élément du carrousel sélectioné ? (30:53) #

            Par la suite, le fait de cliquer sur un titre permet d'ouvrir la vidéo de présentation Apple directement au moment indiqué.


            -

            Cas d'usage (00:48) #

            +

            Cas d'usage (00:48) #

            Les différentes utilisations possibles de cette fonctionnalité sont décrites dans cette partie.


            -

            Par où commencer ? (02:03) #

            +

            Par où commencer ? (02:03) #

            Pour utiliser une voix synthétisée, il est primordial de créer tout d'abord une instance AVSpeechSynthesizer en s'assurant de son existence programmatique jusqu'à la fin de la vocalisation souhaitée.


            Il faut ensuite décrire sous forme de texte ce qui doit être vocalisé et fournir le résultat obtenu à l'instance précédente.
            @@ -256,7 +256,7 @@



            Cette session devra être explicitement désactivée à la disparition de l'instance AVSpeechSynthesizer.


            -

            AVSpeechSynthesizerDelegate (03:20) #

            +

            AVSpeechSynthesizerDelegate (03:20) #

            Ce protocole comprend un ensemble de méthodes optionnelles permettant de gérer certains événements du synthétiseur vocal :

            • @@ -271,25 +271,25 @@




              -

              Démonstration (04:11) #

              +

              Démonstration (04:11) #

              Exemple très simple d'une vocalisation synthétisée s'appuyant sur les méthodes du protocole AVSpeechSynthesizerDelegate.



              -

              Choix de la voix synthétisée (04:31) #

              +

              Choix de la voix synthétisée (04:31) #

              La voix synthétisée par défaut est celle du langage défini dans les préférences du terminal.


              Il est toutefois possible de définir cette dernière en spécifiant le langage désiré ou en utilisant un identifiant propre à une voix téléchargée.



              -

              Débit vocal (05:32) #

              +

              Débit vocal (05:32) #

              La vitesse du débit vocal peut être modifiée avec des coefficients multiplicateurs plus ou moins importants selon la valeur programmatique implémentée.



              -

              Hauteur tonale et volume (06:15) #

              +

              Hauteur tonale et volume (06:15) #

              Ces deux propriétés vocales sont facilement personnalisables en notant bien que l'augmentation du volume de la voix ne modifie absolument pas le volume système.



              -

              Phonétique (06:54) #

              +

              Phonétique (06:54) #

              La prononciation de certains mots pouvant parfois prêter à confusion, il est très pratique d'utiliser la phonétique pour s'assurer de la vocalisation appropriée.

              Côté développement, on s'appuie sur les Attributed Strings pour utiliser l'alphabet phonétique international (IPA), ces éléments pouvant aussi servir à spécifier une langue différente uniquement pour une partie de la phrase à vocaliser par exemple.

              diff --git a/fr/mobile/ios/wwdc/2019/261/index.html b/fr/mobile/ios/wwdc/2019/261/index.html index 7e6a60eb6..3ae75345c 100644 --- a/fr/mobile/ios/wwdc/2019/261/index.html +++ b/fr/mobile/ios/wwdc/2019/261/index.html @@ -235,24 +235,24 @@

              WWDC 2019 : Large Content Viewer

            Par la suite, selon la configuration de la présentation, le fait de cliquer sur un titre ou un temps indiqué permet d'ouvrir la vidéo Apple directement au moment spécifié.


            -

            Dynamic Type (00:57) #

            +

            Dynamic Type (00:57) #

            Petit rappel sur la fonctionnalité Dynamic Type dont le but est de permettre l'adaptation graphique à la taille des polices modifiable dans les réglages utilisateurs.


            Une explication détaillée de l'implémentation de cette fonctionnalité est disponible dans la partie guide pour les développeurs.


            -

            Large Content Viewer (01:54) #

            +

            Large Content Viewer (01:54) #

            Cette fonctionnalité iOS 11 disponible uniquement quand l'option Tailles de police plus grandes est activée permet de rendre très efficace le grossissement des éléments de barres (navigation, onglets...) pour les personnes souhaitant grossir la taille des polices à l'aide du Dynamic Type.

            Le déclenchement de cette fonctionnalité s'effectue par un appui long sur l'élément concerné que l'on peut laisser glisser sur les éléments voisins pour les grossir à leur tour et finalement activer celui sur lequel on relève le doigt de l'écran.


            Il est très important d'avoir à l'esprit que les modifications de taille liées au Dynamic Type doivent toujours être implémentées de façon P.R.I.O.R.I.T.A.I.R.E. : le Large Content Viewer n'est à utiliser qu'à partir du moment où l'élément graphique impacté ne peut pas répondre aux changements souhaités.


            -

            Images (04:02) #

            +

            Images (04:02) #

            Dans cette partie de la vidéo, toutes les caractéristiques des images à importer sont passées en revue pour obtenir une excellente définition du rendu après grossissement comme détaillé dans la partie guide pour les développeurs.

            L'interface graphique de Xcode peut être utilisée conjointement à du code pour obtenir le résultat escompté.



            -

            Custom Views (04:52) #

            +

            Custom Views (04:52) #

            En implémentant le Dynamic Type, iOS 13 rend possible un même rendu graphique pour un élément standard UIKit d'une barre (navigation, onglets...) et pour une UIView.


            Le protocole UILargeContentViewerItem (05:35) définit toutes les informations nécessaires au Large Content Viewer ⟹ la classe UIView se conforme à ce protocole par défaut :
            @@ -264,7 +264,7 @@

            07:52) qui permettent de réaliser certaines actions :



            -

            Exemples (09:15) #

            +

            Exemples (09:15) #

            Le premier exemple concerne les éléments UIKit standards.


            Le second exemple traite de classes personnalisées pour des boutons (09:53) dont certaines propriétés doivent être redéfinies pour une parfaite implémentation du Large Content Viewer.
            diff --git a/fr/mobile/ios/wwdc/2019/index.html b/fr/mobile/ios/wwdc/2019/index.html index 6098f1062..6ff1003a5 100644 --- a/fr/mobile/ios/wwdc/2019/index.html +++ b/fr/mobile/ios/wwdc/2019/index.html @@ -231,7 +231,7 @@

            WWDC 2019 : Quelques enseignements en accessibilité


          Par la suite, selon la configuration de la présentation, le fait de cliquer sur un titre ou un temps indiqué permet d'ouvrir la vidéo Apple directement au moment spécifié.


          -

          Nouveautés iOS 13 pour l'accessibilité visuelle #

          +

          Nouveautés iOS 13 pour l'accessibilité visuelle #

          Cette présentation visualisable sur le site développeur officiel d'Apple (session 244) développe certains points pour rendre une application la plus accessible possible au niveau visuel.


          Les thèmes abordés au sein de la vidéo sont détaillés ci-dessous :

          @@ -260,7 +260,7 @@

          Nouveau



        -

        Dynamic Type #

        +

        Dynamic Type #

        -

        Structurer les tableaux de données #

        +

        Structurer les tableaux de données #

        Cible : tout le monde, et en particulier les personnes déficientes visuelles.
        Quand : dès la phase de conception et lors du développement.

        Description :

        diff --git a/fr/web/developper/couleurs-et-contrastes/index.html b/fr/web/developper/couleurs-et-contrastes/index.html index 79983f720..c953afd92 100644 --- a/fr/web/developper/couleurs-et-contrastes/index.html +++ b/fr/web/developper/couleurs-et-contrastes/index.html @@ -279,7 +279,7 @@

        Thématiques

        Web développer - Couleurs et contrastes

        S’assurer que les couleurs utilisées ne posent pas de problème à l’utilisateur

        -

        Assurer un contraste suffisant entre les couleurs de premier plan et de fond #

        +

        Assurer un contraste suffisant entre les couleurs de premier plan et de fond #

        Cible : tout le monde, en particulier les utilisateurs sur mobile et tablette, les personnes malvoyantes, éprouvant des difficultés de lecture ou avec un déficit d’attention et les seniors.
        Quand : dès la phase de conception et lors du développement.

        Description :
        @@ -329,7 +329,7 @@

        1.4.3 Contrast (Minimum)

      • 1.4.11 Non-text Contrast
      -

      Ne pas utiliser la couleur ou l’information sensorielle comme seule source d’information #

      +

      Ne pas utiliser la couleur ou l’information sensorielle comme seule source d’information #

      Cible : tout le monde, en particulier les daltoniens et plus généralement les personnes malvoyantes ou ayant une déficience cognitive, auditive et les seniors.
      Quand : dès la phase de conception et lors du développement.

      Description :
      diff --git a/fr/web/developper/mise-en-page/index.html b/fr/web/developper/mise-en-page/index.html index cbb62b29a..6e1c3b492 100644 --- a/fr/web/developper/mise-en-page/index.html +++ b/fr/web/developper/mise-en-page/index.html @@ -279,7 +279,7 @@

      Thématiques

      Web développer - Mise en page

      S’assurer que la mise en page soit adaptée à l’utilisateur.

      -

      Utiliser des tailles relatives et faire du web adaptatif #

      +

      Utiliser des tailles relatives et faire du web adaptatif #

      Cible : tout le monde, et en particulier les personnes déficientes visuelles, en mobilité et seniors.
      Quand : lors du développement.

      Description :

      @@ -303,7 +303,7 @@

      1.4.4 Resize text

    • 1.4.10 Reflow
    -

    Permettre d'aérer le texte #

    +

    Permettre d'aérer le texte #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, avec des limitations cognitives (dyslexique) et celles avec un déficit d'attention.
    Quand : lors de la conception et du développement.

    Si l'utilisateur applique les réglages suivants, le texte doit rester lisible (pas de contenu tronqué, superposé):

    @@ -333,7 +333,7 @@

    Permettre d'aérer le texte -

    Assurer un ordre de lecture du contenu compréhensible #

    +

    Assurer un ordre de lecture du contenu compréhensible #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives ou avec un trouble de l’attention et en mobilité.
    Quand : lors du développement.

    Description :

    @@ -357,7 +357,7 @@

    -

    Identifier et conserver la cohérence des regroupements et des différentes régions de la page #

    +

    Identifier et conserver la cohérence des regroupements et des différentes régions de la page #

    Cible : tout le monde et en particulier les personnes déficientes visuelles, cognitives ou ayant des troubles de l’attention.

    Description :
    Fournir des moyens d’identifier et de distinguer visuellement les différentes parties de la page et assurer la cohérence de ces régions ou regroupements dans toutes les pages.

    @@ -385,7 +385,7 @@

    3.2.3 Consistent Navigation
  • 3.2.4 Consistent Identification
  • -

    Définir des zones sensibles de taille suffisante #

    +

    Définir des zones sensibles de taille suffisante #

    Cible : tout le monde en particulier les personnes souffrant de handicap moteur ou visuel et en mobilité.
    Quand : lors de la conception et lors du développement.

    Description :
    @@ -395,7 +395,7 @@

    Défi
  • La taille des zones tactiles doit être de 9mm minimum de largeur et de hauteur.
  • L'espacement entre les zones tactiles ne doit pas être inférieur à 2mm.
  • -

    Séparer le contenu de l’interactivité et de la présentation #

    +

    Séparer le contenu de l’interactivité et de la présentation #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, avec des difficultés pour lire ou avec un déficit d’attention.
    Quand : lors du développement.

    Description :

    diff --git a/fr/web/developper/navigation-generale/index.html b/fr/web/developper/navigation-generale/index.html index 510e90c4e..eb51bcf54 100644 --- a/fr/web/developper/navigation-generale/index.html +++ b/fr/web/developper/navigation-generale/index.html @@ -279,7 +279,7 @@

    Thématiques

    Web développer - Navigation générale

    S’assurer que l’utilisateur navigue facilement dans une page et plus globalement dans un site

    -

    Rendre les intitulés des liens et des boutons accessibles #

    +

    Rendre les intitulés des liens et des boutons accessibles #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives ou ayant un déficit d’attention et les utilisateurs de commande vocale.
    Quand : dès la phase de conception et lors du développement.

    Description :

    @@ -333,7 +333,7 @@

    2.4.9 Link Purpose (Link Only)
  • 2.5.3 Label in Name
  • -

    Prévenir l’utilisateur de l’ouverture d’une nouvelle fenêtre #

    +

    Prévenir l’utilisateur de l’ouverture d’une nouvelle fenêtre #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives ou ayant un déficit d’attention.
    Quand : dès la phase de conception et lors du développement.

    Description :

    @@ -358,7 +358,7 @@

    3.2.2 On Input -

    Fournir des liens d’évitement #

    +

    Fournir des liens d’évitement #

    Cible : utile pour les utilisateurs de mobile et tablette, les personnes déficientes visuelles et les personnes souffrant de handicap moteur ou en mobilité.
    Quand : dès la phase de conception et lors du développement.

    Description :

    @@ -375,7 +375,7 @@

    Fournir des liens d’év -

    S’assurer que l’utilisateur garde le contrôle lors des interactions #

    +

    S’assurer que l’utilisateur garde le contrôle lors des interactions #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives ou avec un déficit d’attention, les utilisateurs qui augmentent la taille du pointeur souris, avec des mouvements peu précis et ceux qui utilisent la commande vocales.

    Quand : dès la phase de conception et lors du développement.

    Description :

    @@ -417,7 +417,7 @@

    3.2.2 On Input
  • 2.1.4 Character key shortcuts
  • -

    Fournir des accès multiples et une localisation #

    +

    Fournir des accès multiples et une localisation #

    Cible : tout le monde et en particulier les personnes déficientes visuelles ou cognitives.

    Description :
    Donner à l’utilisateur plusieurs moyens de situer et accéder à un contenu spécifique, localiser la page Web en cours de consultation dans un ensemble de pages. Lorsque la page est une étape dans un processus où les pages s’enchaînent les unes après les autres, l’implémentation d’accès multiples peut être ignorée.

    @@ -434,7 +434,7 @@

    Fourni
  • 2.4.5 Multiple Ways
  • 2.4.8 Location
  • -

    Permettre de connaître le résultat d'une interaction utilisateur à l'aide de messages contextuels #

    +

    Permettre de connaître le résultat d'une interaction utilisateur à l'aide de messages contextuels #

    Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives et des troubles de l'attention.
    Quand : dès la conception, à la rédaction du contenu et pendant le développement.

    Description :
    @@ -455,7 +455,7 @@

    4.1.3 Status Messages -

    Permettre le contrôle des animations #

    +

    Permettre le contrôle des animations #

    Cible : les personnes malvoyantes, les personnes éprouvant des difficultés de lecture, d’attention ou de compréhension, les personnes épileptiques.
    Quand : lors de la conception du service et lors de la conception graphique.

    Description :
    diff --git a/fr/web/developper/tactile-et-interactions/index.html b/fr/web/developper/tactile-et-interactions/index.html index 01564d1cb..ba47ea160 100644 --- a/fr/web/developper/tactile-et-interactions/index.html +++ b/fr/web/developper/tactile-et-interactions/index.html @@ -279,12 +279,12 @@

    Thématiques

    Web développer - Tactile et interactions

    S’assurer que l’utilisateur garde le contrôle sur les interactions, en particulier tactiles

    -

    Autoriser l'utilisation du zoom #

    +

    Autoriser l'utilisation du zoom #

    Cible : tout le monde en particulier les personnes déficientes visuelles.
    Quand : lors du développement.

    Description :
    L'utilisateur doit être capable de zoomer le contenu de la page facilement sur périphérique tactile (smartphone, tablette...). Cette fonctionnalité de base offerte par le navigateur ne doit pas être désactivée au niveau du code (ne pas utiliser de balise meta interdisant le zoom).

    -

    Permettre d'annuler le déclenchement des interactions #

    +

    Permettre d'annuler le déclenchement des interactions #

    Cible : Facilite l'annulation pour tous les utilisateurs en cas d'erreur sur la cible.
    Aide les personnes ayant des déficiences visuelles, des limitations cognitives et des déficiences motrices.
    Les personnes incapables de détecter les changements de contexte sont moins susceptibles d'être désorientées lors de la navigation sur un site.

    @@ -301,7 +301,7 @@

    P -

    Proposer une alternative aux gestuelles complexes #

    +

    Proposer une alternative aux gestuelles complexes #

    Cible : tout le monde en particulier les personnes souffrant de handicap moteur ou visuel, de troubles cognitifs ou d'apprentissage et en mobilité. Les utilisateurs qui ne peuvent pas (avec précision) effectuer des gestes complexes avec un pointeur. Les utilisateurs novices qui ignorent souvent la prise en charge de gestes de pointeur complexes.

    Quand : lors de la conception et lors du développement.

    Description :

    @@ -316,7 +316,7 @@

    Prop
  • 2.5.1 Pointer Gestures
  • 2.5.4 Motion Actuation
  • -

    Proposer une alternative aux mouvements de glisser-déposer #

    +

    Proposer une alternative aux mouvements de glisser-déposer #

    Cible : tout le monde en particulier les personnes souffrant de handicap moteur, visuel et en mobilité.
    Quand : lors de la conception et lors du développement.

    Description :
    @@ -331,7 +331,7 @@

    2.5.7 Dragging movements -

    Donner accès au contenu quelle que soit l'orientation de l'écran #

    +

    Donner accès au contenu quelle que soit l'orientation de l'écran #

    Cible : tout le monde en particulier les personnes souffrant de handicap moteur ou visuel et en mobilité.
    Quand : lors de la conception et lors du développement.

    Description :
    diff --git a/fr/web/index.html b/fr/web/index.html index 75d63ed05..e40d7f53d 100644 --- a/fr/web/index.html +++ b/fr/web/index.html @@ -186,7 +186,7 @@

    Recommandations et outils pour accessibilité web Orange

    L’accessibilité, un avantage pour tous, une nécessité pour certains, un droit pour les personnes handicapées !

    -

    Définition de l’accessibilité web #

    +

    Définition de l’accessibilité web #

    C’est un service web utilisable par tous

    • Personnes valides
    • @@ -199,16 +199,16 @@

      Définition de l’ac
    • Dans un contexte dégradé : mauvaise luminosité, touchpad en mobilité, etc.
    • Avec des logiciels spécifiques de compensation du handicap
    -

    Organisation de cette rubrique "Web" #

    -

    Designer #

    +

    Organisation de cette rubrique "Web" #

    +

    Designer #

    Liste des critères principaux à prendre en compte en phase de maquettage, basés sur un sous-ensemble des recommandations WCAG (Web Content Accessibility Guidelines) 2.1 niveau AA.

    -

    Développer #

    +

    Développer #

    Section à destination des développeurs. Tout ce qu’il faut savoir pour coder accessible, l'ensemble des critères WCAG (Web Content Accessibility Guidelines) 2.1 niveau AA, rangés par thématique.

    -

    Tester #

    +

    Tester #

    Pour ceux qui veulent vérifier l’accessibilité de leurs pages avec des outils plus ou moins automatiques quel que soit votre profil : designer UX/UI, développeur, testeur, expert accessibilité. Enfin, tout l’outillage méthodologique et technique pour évaluer ses pages.

    -

    Auditer #

    +

    Auditer #

    La Va11ydette, notre outil opensource qui nous aide lors de nos audits et nos déclarations de conformité. C'est une application Web, PWA (Progressive Web App), à tester !

    -

    Boite à outils #

    +

    Boite à outils #

    Méthode et outils internes et externe que nous utilisons dans notre activité. Notamment, le design system d'Orange, Orange Boosted, nos Fiches mémos pour avoir toutes les bonnes pratiques d'accessibilité, des Personae pour mieux comprendre les problématiques d'accessibilité...

    diff --git a/fr/web/liens-utiles/index.html b/fr/web/liens-utiles/index.html index a76efec47..69871e1b5 100644 --- a/fr/web/liens-utiles/index.html +++ b/fr/web/liens-utiles/index.html @@ -190,11 +190,11 @@

    Web - Référentiels et ressources

    -

    Le référentiel WCAG #

    +

    Le référentiel WCAG #

    Pour les exigences d’accessibilité interne d’Orange, nous avons choisi de nous appuyer sur les Web Content Accessibility Guidelines v2.1 (WCAG 2.1). Il s’agit des recommandations internationales éditées par le groupe de travail Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C) qui sont aussi les normes ISO 40500:2012.

    Le niveau d’accessibilité demandé à toute interface HTML par le groupe Orange est le respect des critères du niveau AA des Web Content Accessibility Guidelines (WCAG) 2.1, sans point bloquant suite à un test utilisateur d’aide technique pour les principaux scénarios d’utilisation des fonctionnalités du site ou de l’application.

    Pour les solutions à mettre en place afin de respecter cet objectif, nous vous conseillons la consultation des critères WCAG par thème et des exemples de ce site. Vous pouvez aussi utiliser les notices Accede-Web cf. ci-dessous.

    -

    Le référentiel général d’amélioration de l'accessibilité (RGAA) #

    +

    Le référentiel général d’amélioration de l'accessibilité (RGAA) #

    Si vous êtes familiarisé avec le Référentiel Général d’Amélioration de l'accessibilité (RGAA), celui-ci peut être utilisé pour effectuer les tests d’accessibilité.
    Il s’agit du référentiel officiel permettant de s’assurer qu’un site d’état et de collectivités territoriales est en conformité avec l’article 47 de la loi de février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées.

    Le RGAA est une méthode d’implémentation des Web Content Accessibility Guidelines (WCAG). Un site conforme au RGAA est également conforme aux WCAG.

    diff --git a/fr/web/outils/fiches-memo/index.html b/fr/web/outils/fiches-memo/index.html index 32038eeb6..1df671582 100644 --- a/fr/web/outils/fiches-memo/index.html +++ b/fr/web/outils/fiches-memo/index.html @@ -264,7 +264,7 @@

    Thématiques

    Les fiches mémos accessibilité pour le Web

    Des fiches mémos au format PDF contenant un rappel des critères incontournables à respecter pour créer ou pour tester l'accessibilité d'un site Web.

    -

    Développer des pages Web accessibles #

    +

    Développer des pages Web accessibles #

    @@ -285,7 +285,7 @@

    Téléchargement


    -

    Tester l'accessibilité de pages Web #

    +

    Tester l'accessibilité de pages Web #

    diff --git a/fr/web/outils/methodes-et-outils-de-test/agrandissement-texte/index.html b/fr/web/outils/methodes-et-outils-de-test/agrandissement-texte/index.html index 595fe586b..54882cc73 100644 --- a/fr/web/outils/methodes-et-outils-de-test/agrandissement-texte/index.html +++ b/fr/web/outils/methodes-et-outils-de-test/agrandissement-texte/index.html @@ -263,12 +263,12 @@

    Thématiques

    Agrandissement de la taille du texte

    -

    Comment on teste ? #

    +

    Comment on teste ? #

    Une des recommandations d’accessibilité est la possibilité pour l’utilisateur d’agrandir la taille du texte à 200%. Il s’agit bien d’agrandir uniquement le texte et non l’ensemble de la page. En effet, si vous utilisez le zoom par défaut du navigateur, toute la page est agrandie, ce qui entraîne l’apparition systématique d’ascenseurs horizontaux et verticaux. La lecture d’un article de blog par exemple devient fastidieuse puisqu’il faut jouer constamment avec l’ascenseur horizontal.

    L’agrandissement du texte seul, n’entraîne pas systématiquement l’apparition de barres de défilement horizontale. Vous devez vérifier qu’a ce niveau de zoom (200%), le texte reste lisible. Aucun texte ne doit être tronqué, ni superposé. L’information doit rester accessible même si la présentation peut être quelque peu altérée.

    Pour agrandir le texte uniquement, il faut cocher l’option « zoom texte seulement » dans Firefox. Pour agrandir le texte de 200%, faire Ctrl :+ quatre fois.

    capture d’écran de l’option zoom texte seulement, dans Firefox

    -

    Quelles conséquences sur le développement ? #

    +

    Quelles conséquences sur le développement ? #

    Si votre page ne s’affiche pas correctement lorsque vous agrandissez le texte, il se peut que ceci soit lié à l’utilisation du pixel comme unité pour dimensionner la taille des textes et la taille des éléments (hauteur ou largeur des div…).
    Pour corriger les problèmes d’affichage lorsque le zoom est à 200%, il ne s’agit pas nécessairement de tout revoir et de supprimer les pixels définitivement. L’idée est de revoir uniquement les éléments qui posent un problème (remplacer les px par des em, rem ou %).

    Exemple zoom à 100%
    diff --git a/fr/web/outils/methodes-et-outils-de-test/desactiver-les-css/index.html b/fr/web/outils/methodes-et-outils-de-test/desactiver-les-css/index.html index 24e2c26da..4bbdfd246 100644 --- a/fr/web/outils/methodes-et-outils-de-test/desactiver-les-css/index.html +++ b/fr/web/outils/methodes-et-outils-de-test/desactiver-les-css/index.html @@ -265,23 +265,23 @@

    Thématiques

    Tester en désactivant les CSS

    La désactivation des CSS est un bon moyen de s'assurer du respect de certaines bonnes pratiques et de valider quelques critères importants d'accessibilité.
    Pour désactiver les CSS, le plus simple est de d'installer l'extentsion "Web developer toolbar" pour FireFox ou Chrome (https://chrispederick.com/work/web-developer/). Une fois celle-ci en place, cliquer sur le menu "CSS", puis "Désactives tous les styles".

    -

    Séparer le contenu de la présentation #

    +

    Séparer le contenu de la présentation #

    Même si ce n'est qu'une bonne pratique, la séparation stricte des CSS et du HTML est importante en ce qui concerne la qualité de code et la maintenabilité de celui-ci et a parfois un impact sur l'accessibilité, en limitant les possibilités de modification du rendu visuel des pages.

    En désactivant les CSS, l'affichage de la page se fait avec les styles par défaut du navigateur (lien en bleu souligné, texte en noir, fond en blanc...). Ceci permet de vérifier que le contenu n'est pas stylé par des CSS en ligne.

    capture d’écran d'une page avec les CSS désactivées

    -

    Ordre de lecture et contenu caché #

    +

    Ordre de lecture et contenu caché #

    L'ordre d'apparition dans le code de contenu doit respecter l'ordre d'affichage visuel, si cela a un impact sur la compréhension. Le problème peut se poser du fait, entre autre, de l'utilisation de propriétés CSS de type position:,float:, display:flexbox (https://wiki.csswg.org/spec/css3-flexbox/accessibility) ou display:grid (https://webdesign.tutsplus.com/articles/a-guide-to-css-grid-and-accessibility--cms-32857). En effet, ces propriétés peuvent modifier l'ordre d'affichage de contenu.

    Le contenu caché, pouvant être affiché par une action utilisateur, doit, lui aussi, s'afficher au bon endroit dans la page pour que l'ordre de lecture soit compréhensible.

    En désactivant les CSS, l'affichage du contenu de la page se fait dans l'ordre d'apparition dans le code, c'est donc facile de vérifier que le contenu est compréhensible dans cet ordre.

    Attention : De plus, on peut voir apparaître le contenu caché visuellement et destiné aux aides techniques (masquage accessible) et donc vérifier sa pertinence et sont utilité.

    -

    Sémantique du contenu et tableau de présentation #

    +

    Sémantique du contenu et tableau de présentation #

    Pour être accessible, le contenu d'une page doit avoir une structure sémantique qui permet de mieux en comprendre le sens.

    En désactivant les CSS, l'affichage de la page se fait avec les styles par défaut du navigateur (lien en bleu souligné, texte en noir, fond en blanc...). Ceci permet de vérifier que le contenu est sémantisé avec des listes, des emphases, des paragraphes, des titres...

    Et que le contenu n'est pas mis en page avec des tableaux HTML, car, dès lors, il s'affiche toujours sous forme de tableau même en désactivant CSS. Même si ce n'est pas une erreur d'accessibilité, c'est une très mauvaise pratique.

    -

    Information portée par la couleur #

    +

    Information portée par la couleur #

    L'information ne doit pas être portée que par la couleur.

    En désactivant les CSS, on désactive les styles et donc les couleurs. On peut ainsi vérifier que de l'information n'est pas passée que par une couleur.

    -

    Contenu informatif généré via CSS #

    +

    Contenu informatif généré via CSS #

    Du contenu peut être généré par CSS via des pseudo-éléments (::before, ::after) ou la propriété content:. Il n'est pas conseillé de générer du contenu informatif avec de telles méthodes car leur support est mauvais pour les anciennes version d'aides techniques, donc à éviter et à tester !
    Pour la propriété background-image:, le risque est d'afficher des images porteuses d'information en CSS qui seront inaccessibles aux aides techniques.

    En désactivant les CSS, on désactive les règles impliquant les pseudo-éléments et on ignore la propriété content:, donc on peut identifier le contenu généré par CSS et voir s'il y perte d'information. Pour des images insérées en CSS porteuses d'informations, elles disparaîtrons sans CSS et c'est une erreur d'accessibilité à laquelle il faut être vigilant.

    diff --git a/fr/web/outils/methodes-et-outils-de-test/extensions-navigateur/index.html b/fr/web/outils/methodes-et-outils-de-test/extensions-navigateur/index.html index 78875ee2f..7af9f9536 100644 --- a/fr/web/outils/methodes-et-outils-de-test/extensions-navigateur/index.html +++ b/fr/web/outils/methodes-et-outils-de-test/extensions-navigateur/index.html @@ -272,21 +272,21 @@

    Extensions pour navigateur

  • Les résultats obtenus ne reflètent pas le taux de conformité ou le niveau d’accessibilité du site inspecté mais permettent tout de même d’estimer une tendance.
  • Les référentiels (RGAA et WCAG) sont mis à jour régulièrement, pensez donc à vérifier les dates de mises à jour de l’outil que vous sélectionnerez.
  • -

    Testé par nos soins : aXe de Deque Systems #

    +

    Testé par nos soins : aXe de Deque Systems #

    Deque Systems propose aXe, une extension pour Chrome et une pour Firefox permettant d’effectuer une série de tests basés sur les critères d’accessibilité WCAG, remontant les erreurs dans un onglet de l’inspecteur web des outils développeur et proposant même dans la plupart des cas des pistes de solution.
    La philosophie repose sur le fait de minimiser les faux positifs (erreurs qui n’en sont pas) et de proposer au-delà de la conformité stricte WCAG, une série de bonnes pratiques utiles aux développeurs.

    capture d’écran d'axe
     

    -

    Testé par nos soins : Wave de WebAIM #

    +

    Testé par nos soins : Wave de WebAIM #

    Développé par WebAIM.org, même idée pour Wave à la différence près qu’il remonte également des alertes (demandent une vérification manuelle) et que les résultats sont présentés dans un encart à part. L’outil ajoute des icônes et des indicateurs directement dans la page testée afin de vous aider à cibler les erreurs et alertes.

    capture d’écran wave

    -

    Liens connexes #

    +

    Liens connexes #

    -

    Glossaire #

    +

    Glossaire #

    • CSS : Cascading Stylesheets, feuilles de style en cascade
    • DOM : Document Object Model, modèle d’objet document
    • diff --git a/fr/web/outils/methodes-et-outils-de-test/index.html b/fr/web/outils/methodes-et-outils-de-test/index.html index 3107ff747..4f5e06790 100644 --- a/fr/web/outils/methodes-et-outils-de-test/index.html +++ b/fr/web/outils/methodes-et-outils-de-test/index.html @@ -263,7 +263,7 @@

      Thématiques

      Méthodes et outils de test

      -

      Introduction #

      +

      Introduction #

      Cette partie décrit une méthode d’évaluation à destination des acteurs projet pour tester la conformité d’un contenu Web et Web mobile aux critères d’accessibilité des Web Content Accessibility Guidelines (WCAG) version 2.1 niveau AA.

      Pour utiliser cette méthode, voici la description détaillée des tests d'accessibilité à utiliser, en fonction de différents profils : qualifieurs, développeurs, concepteurs et experts.

      Les tests d’accessibilité doivent être effectués tout au long du cycle de vie des projets :

      @@ -273,15 +273,15 @@

      Introduction lors des développements et des tests
    • en production, pour les sites de contenu
    -

    Méthode générale #

    +

    Méthode générale #

    La démarche comprend 2 types de tests :

    • Des tests techniques qui consistent à inspecter le code et le contraste des couleurs.
    • Des tests fonctionnels qui permettent de tester le comportement de l’interface avec différentes aides techniques pour vérifier que les contenus évalués sont exempts de points bloquants.

    En fonction de votre profil, vous pouvez réaliser les tests techniques, les tests fonctionnels ou les deux, sachant que les deux sont nécessaires pour tester l’accessibilité d’un site Web dans sa globalité.

    -

    Méthode pour tester le Web #

    -

    Évaluation technique #

    +

    Méthode pour tester le Web #

    +

    Évaluation technique #

    Une partie des tests peut-être réalisée automatiquement par des outils, mais la majorité nécessite un contrôle manuel.

    Ces tests peuvent être réalisés par tout acteur du projet ( concepteur, développeur, testeur, rédacteur…).

    Démarche :

    @@ -292,7 +292,7 @@

    Évaluation technique Désactiver les CSS pour vérifier plusieurs critères facilement
  • Tous les autres tests doivent être passés via une revue de code manuelle, par exemple, tous les critères de pertinence (alternative textuelle cohérente avec le contenu d’une image…)
  • -

    Évaluation fonctionnelle #

    +

    Évaluation fonctionnelle #

    Ces tests peuvent être facilement réalisés par tout acteur projet. Seuls les lecteurs d’écran nécessitent un temps d’apprentissage.

    Démarche :

    -

    Méthode pour tester le Web mobile #

    -

    Évaluation technique #

    +

    Méthode pour tester le Web mobile #

    +

    Évaluation technique #

    Les tests à réaliser pour le web mobile sont identiques à ceux réalisés pour le web. Une partie des tests peut être réalisée à partir d’un ordinateur via les outils de développements présents dans les navigateurs :

    • le module Vue adaptative sur Firefox
    • Device Toolbar sur Chrome
    -

    Évaluation fonctionnelle #

    +

    Évaluation fonctionnelle #

    Ces tests doivent être réalisés sur smartphone, à l’aide des lecteurs d’écran mis à disposition sur iOS et Android :

    • Talkback sous Android
    • diff --git a/fr/web/outils/methodes-et-outils-de-test/navigation-clavier/index.html b/fr/web/outils/methodes-et-outils-de-test/navigation-clavier/index.html index 214bddbc4..74bb500f7 100644 --- a/fr/web/outils/methodes-et-outils-de-test/navigation-clavier/index.html +++ b/fr/web/outils/methodes-et-outils-de-test/navigation-clavier/index.html @@ -266,7 +266,7 @@

      Navigation à l’aide du clavier

      La navigation dans une page web doit être possible à l’aide du clavier seul, notamment pour les personnes qui ne peuvent pas utiliser de souris. Cette fonctionnalité est prise en charge directement par le navigateur. Il est tout de même important de vérifier son fonctionnement, car certains développements peuvent entraîner des difficultés pour naviguer correctement dans la page.

      Pour tester si votre service est accessible à l’aide du clavier, vous pouvez tenter de naviguer sans votre souris. Toutes les fonctionnalités disponibles habituellement doivent rester accessible.

      Rappel : le focus doit rester suffisamment visible sur tous les éléments recevant le focus lors de la navigation clavier.

      -

      Liste des raccourcis clavier principaux : #

      +

      Liste des raccourcis clavier principaux : #

      présentation des raccourcis clavier

      diff --git a/fr/web/outils/methodes-et-outils-de-test/navigation-lecteur-ecran/index.html b/fr/web/outils/methodes-et-outils-de-test/navigation-lecteur-ecran/index.html index e813a1fc1..dcfa0d1dc 100644 --- a/fr/web/outils/methodes-et-outils-de-test/navigation-lecteur-ecran/index.html +++ b/fr/web/outils/methodes-et-outils-de-test/navigation-lecteur-ecran/index.html @@ -270,18 +270,18 @@

      Navigation à l’aide d’un lecteur d’écran

    • JAWS : payant disponible pour Windows. En mode démonstration, vous pouvez l’utiliser 40 min, après quoi il faudra redémarrer votre ordinateur pour l’utiliser à nouveau.
    • VoiceOver : disponible pour Mac. Il est gratuit et intégré directement au système MacOS.
    • -

      Prise en main de NVDA #

      +

      Prise en main de NVDA #

      NVDA est un lecteur d’écran gratuit disponible pour Windows.

      -

      Installation #

      +

      Installation #

      Télécharger le fichier d’installation de NVDA sur le site officiel.

      La voix par défaut n’est pas de très bonne qualité mais elle est très réactive. Ce n’est pas indispensable, mais le téléchargement d’une voix de meilleure qualité est conseillé comme celle d’Hortense. Il suffit ensuite de se rendre dans les préférences de NVDA pour modifier les paramètres vocaux.

      -

      Configuration #

      +

      Configuration #

      Au premier démarrage, NVDA est configuré pour vocaliser tout ce que survole le pointeur de la souris. Ce mode est utilisé par certaines personnes malvoyantes qui ont des difficultés à lire les textes affichés à l’écran par exemple. Il est conseillé de désactiver cette option si vous utilisez NVDA pour faire des tests d’accessibilité sur vos pages.

      1. Pour désactiver ce mode de navigation, faites un clic droit sur l’icône de NVDA dans la barre Windows à côté de l’heure. Puis aller dans Préférences > Paramètres de la souris et désactiver la case « Activer le suivi de la souris ».
      2. Enfin, toujours dans les préférences, rubrique "Mode Navigation", décocher la case "Utiliser la disposition telle qu'à l'écran". Cela indique à NVDA de faire une pause par exemple entre deux boutons qui apparaissent sur une même ligne.
      - +

      Voici les principaux raccourcis utiles pour tester la navigation au sein d’une page web à l’aide de NVDA :

      • Ctrl+Alt+N pour démarrer NVDA.
      • @@ -313,11 +313,11 @@ +

        Prise en main de Jaws #

        Jaws est un lecteur d’écran payant très utilisé, disponible pour Windows. Il est à utiliser en priorité avec Internet Explorer. En mode démonstration, vous pouvez l’utiliser 40 min, après quoi il faudra redémarrer votre ordinateur pour l’utiliser à nouveau.

        -

        Installation #

        +

        Installation #

        Vous pouvez télécharger Jaws directement depuis le site de l’éditeur Freedom Scientific.

        - +

        Voici les principaux raccourcis utiles pour tester la navigation au sein d’une page web à l’aide de Jaws :

        -

        Prise en main de VoiceOver (sous Mac) #

        +

        Prise en main de VoiceOver (sous Mac) #

        VoiceOver est le lecteur d’écran disponible sur Mac. Celui-ci nécessite aucune installation puisqu’il est intégré directement au système.
        Pour pouvez activer VoiceOver depuis les Préférences systèmes > Accessibilité. Ou directement en utilisant le raccourci Commande+F5.

        - +

        Au démarrage de VoiceOver, celui-ci propose un guide interactif permettant d’apprendre les principaux raccourcis clavier. Il est recommandé de le parcourir.
        Voici néanmoins les raccourcis principaux :

        -

        Prise en main des lecteurs d'écran sous mobile #

        +

        Prise en main des lecteurs d'écran sous mobile #

        Pour tester un site web sur mobile :

        • Guide d’utilisation de TalkBack (sous Android)
        • diff --git a/fr/web/outils/orange-boosted/index.html b/fr/web/outils/orange-boosted/index.html index 0336a4b95..332be7220 100644 --- a/fr/web/outils/orange-boosted/index.html +++ b/fr/web/outils/orange-boosted/index.html @@ -263,10 +263,10 @@

          Thématiques

          Orange Boosted

          -

          Présentation #

          +

          Présentation #

          Orange Boosted est un framework HTML, CSS et Javascript basé sur le très populaire Twitter Boostrap.
          Il permet la mise en place rapide d’un site web responsive et accessible aux couleurs de la charte Orange.

          -

          Pourquoi l’utiliser ? #

          +

          Pourquoi l’utiliser ? #

          -

          Site officiel #

          +

          Site officiel #

          Orange Boosted with Bootstrap

      Liste des raccourcis clavier principaux