Geekly Articles each Day
⬆️ ⬇️

Public website accessible to people with disabilities (accessibility checklist)

Introduction



As part of the “State System Design”, we have created for you (developers of all kinds) a checklist of accessibility of the site for people with disabilities, which must be nailed over the desktop of each designer and front-endander. It is suitable for any projects (not only government projects), there is nothing superfluous in it. It contains only extremely important, critical and useful information.

So print, read and share with your colleagues.

This is a very necessary text and knowledge.



Blurred text processed in Photoshop



Site accessibility requirements are defined by the WCAG level AA. The standard describes in some detail all requirements, contains references to explanations, techniques used and common errors. This allows you to fully rely on it when analyzing the availability of web pages and their adaptation. In addition, in general, there is a large toolkit for semi-automatic error detection: validators and add-ons for browsers.



This document presents practical recommendations on the application of the standard, describes the toolkit and the process of checking the site for accessibility, provides links to key materials and guidelines on accessibility of sites, as well as examples of the implementation of the most common widgets.



The AA WCAG 2.0 standard describes accessibility criteria for different categories of users. In practice, in order to maintain a good level of compliance with the criteria, it will be useful for the tester to introduce himself to the following categories of users (or involve them in testing):





All development participants (designers, developers, project managers, testers and editors) can also get acquainted with a short checklist that describes the main responsibilities of each accessibility specialist.



See also:





Design



  1. Color may not be the only way to provide any information or markup.



  2. It is necessary to observe the contrast according to WCAG 2.0.



    You can measure contrast in HTML using the WAVE Evaluation Tool.



  3. Do not rely on sensory characteristics.



    This requirement is detailed below in the description of Criterion 1.3.3.



  4. There should be a visual display of the states of focus in the fields and controls.



  5. For information that cannot be made accessible in principle, alternative forms of presentation should be provided or, if even this is not possible, provide a textual description of the interface's capabilities (for example, so that a blind user can understand the functionality of the page and seek help from a sighted person).


See also Accessibility Guidelines. The Checlist for Designers .



Means of verification



  1. Site validators check for general HTML validity: https://validator.w3.org/



  2. Site verification by specialized validators:



    • http://achecker.ca/checker/ validator based on the analysis of HTML-code. Does not take into account JavaScript, errors are displayed in text form, are not very convenient for analysis. It gives a list of potential problems, most of which are untrue, but the list can be used as an additional checklist.

    • http://wave.webaim.org/ and the Chrome WAVE Evaluation Tool extension. Find a large number of errors, provide hints for correction and a link to the standard, provide information in a convenient form, highlight the syntax and aria-attributes.



      The main convenience is that the extension can analyze not the source code, but the current state of the page.



    • http://khan.imtqy.com/tota11y/ - a visualizer and accessibility validator embedded on the page using the bookmarklet. Supports contrast measurement. Unlike the Wave Evaluation Tool, it does not show all errors at once and does not detect so many errors.
    • AInspector Sidebar for Firefox . Unlike previous validators, it allows you to find errors in the logic of the use of aria-attributes. In addition to the list of errors, it also provides a list of checks that are recommended to be done manually.
    • Accessibility Developer Tools Chrome . Catching mostly formal errors of application of aria-attributes. Of the minuses: inconvenient interface and incomprehensible format of error output.


    It must be remembered that the presence of validator error messages is not in itself a formal criterion for a WCAG nonconformity. In addition, some messages are advisory in nature or marked as potential. Decisions on them should be made on the basis of context.



    The reverse is also true: not every problem is found by the validator: manual testing is necessary, including using screen readers (see below).



  3. Check in screen readers.



    The easiest to set up is the combination of Windows + Firefox / IE + NVDA. JAWS is also widely distributed (the program is paid and expensive, but comes in a trial version with a 40-minute mode). Other OS users can test the test environment in Microsoft virtual machines ( https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ - formerly modern.ie), it works acceptable, at least with VM Windows 7.



    Screen access programs are quite specific for those who encounter them for the first time, but you can get used to them relatively quickly. To master the program at the level of brief instructions (see below) is recommended to all front-end developers and testers. It does not take much time.







Initially, when Werth need to consider



  1. Compliance with markup semantics. In particular, the following can be singled out (far from everything is listed):



    • Marking lists, listing items, document streams, and so on with <ul>, <ol>, <li> tags or the corresponding role attributes.
    • Tabulation of table data with <table>, <tr>, <th>, <td> tags or corresponding role attributes. Please note The rules for nesting elements for role attributes are completely analogous to the rules for tags.
    • Using the tags <caption> and <summary>
    • Proper use of table headers. It should be noted that the cell headers are all the higher <th> elements in the whole table. Colspan headers are applied to each downstream cell in all affected columns.
    • Do not split a table or list into several for display only.
    • Buttons are recommended to be designed using clickable elements: <button>, <a href… role="button">, <input type = "button">. It is also allowed to use non-clickable elements with role = button, subject to focusing (tabindex) and handling keyboard events (keydown by pressing enter).


  2. Markup of semantic areas with the help of role = main, role = navigation, role = contentinfo, role = complementary, role = banner, etc.



    • Any page content must belong to any semantic zone.
    • If on one page a zone with a role equal to navigation or complementary appears more than once, then they should add text signatures explaining their purpose using the aria-label attribute.
    • Adding a link to skip repeating blocks and go to the role = "main" block.


    The link should be the first focusable element on the page. This is a link intended for blind users. After loading the page, the focus should be placed on the link by first pressing TAB, then by pressing ENTER, the page should anchor on the element with the main content.



    Reference implementation at http://webaim.org/ . After downloading, you need to click on the TAB - the link becomes visible in the upper left corner, then ENTER.



  3. Strict header hierarchy starting at level 1.



  4. Keyboard control:



    • All controls and inputs must be focusable.
    • Focus state must be distinguishable


  5. Providing additional text information:



    • Attribute `alt`: empty for decorative elements and meaningful text for informative elements.

    • Providing labels for input elements: using <label for = "...">, aria-label, aria-labelledby. There should be no controls and inputs without text or text label.



      For more information on how the text alternative is computed, see https://www.w3.org/TR/wai-aria/roles#textalternativecomputation



      Note that it does not make sense to add aria-label to non-semantic elements (for example, <span>).



      For other elements (lists, groupings of <fieldset> fields and others, landmarks), the aria-label attribute will also be interpreted differently, and when using it you need to understand its purpose for each element.



    • Displaying errors: a general error message (in the title of the page - title, either at the beginning of the block of the main content of the page, or in elements with role = "alert" or aria-live = "assertive".
    • The use of the <caption> and <summary> tags to describe tables whose purpose is not clear from the previous context or the navigation through which may require additional information.
    • Expansion of abbreviations using <abbr title> (title is read instead of the contents of the tag):


    <abbr title="  ">  .. </abbr>


    • For elements whose meaning becomes clear only taking into account the position on the page or appearance, font style, strikethrough text, presented using information icons (for example, the star of the hotel), a text description is required, possibly hidden by removing the left edge of the screen:


     .sr_only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); border: 0; } 


     <span class="sr_only">     </span>


    • Significant information, presented in the form of diagrams, graphs, interactive Flash (in most cases), SVG, Canvas and others, should also be presented in text form: separate paragraphs, tables, possibly on a separate page or hidden from sighted users with using the class = "sr_only" block.



      Note: in most cases there is a technical possibility to adapt the listed elements for the use of the blind, but in view of labor-intensive, the need to work out essentially a separate interface for the blind, problems with testing, etc. It is usually easier and, more importantly, more convenient for the user to have a textual representation of the data.





  6. If possible, it is recommended to use the built-in browser components if they satisfy the required functionality: comboboxes (<select>), flags (checkbox), radio buttons, buttons, input fields.



    It is also necessary to avoid over-complication of control from the keyboard, not to invent new interaction patterns in the presence of standard solutions solving the same tasks, trying to assemble the interface from components and approaches known and accessible to people with disabilities. See the section "Examples of the implementation of available interfaces" and the description of criterion 4.1.2 below.



  7. It is allowed to create items that are hidden for sighted users, but accessible to blind people. This is done using the technique of removing the element far beyond the left edge of the screen (the sr_only class described above).



  8. It is possible to implement a separate alternative interface for screen readers (with the main interface option hidden) if it is difficult to make a regular widget accessible. At the same time, one should not forget about the controllability of the element from the keyboard by sighted users.



    Use this technique with caution: if there is a choice, then you should prefer to adapt the general interface for use by blind users.



    Implementing a separate interface makes sense if it significantly simplifies the interface for the blind, for example, manually entering a date instead of a calendar (but the calendar can also be made available), using the list instead of a map to select countries / cities.



    It is important not to overdo it: practice shows that blind users have no difficulty in using some interfaces, which at first glance seem inconvenient to the blind.





Quick check



  1. Site checking by validators for general HTML validity: https://validator.w3.org/ .



    The maximum specification of the HTML version used is optional, but recommended (see the [G192] [g192] technique). However, there are a number of errors that are important for the accessibility of the site and are required to correct. They are listed in the description of criterion 4.1.2 in the section "Detailed verification of compliance with WCAG AA".



  2. Site verification by specialized validators. See the section "Means of verification".



  3. Check of controllability from the keyboard without screen readers.



    There should not be clickable elements that are inaccessible from the keyboard (unless they have a special alternative available). Such elements should be implemented using the tags <a href=..> </a>, <button> or using a combination of the attributes role = button, role = link and tabindex.



    The focus must be visible, move correctly, not “stuck” when it hits any element and is not lost during any user action in any state of the page.



  4. View the site with the applied styles that bring it closer to how the blind see it. Styles can be found at https://github.com/Harut/wai-aria.css . This will make it possible to find most of the errors “by eye”, without checking with each item of the checklist. This item is optional, does not replace, but precedes the page in the screen reader. First of all, it is recommended to pay attention to inconsistencies in the full visual version and the version with the applied styles.



  5. Check in screen readers. At this stage, most of the critical errors should be detected and corrected during previous checks.



    It is necessary to check the perception of on-screen readers of the tables, non-standard elements, ease of use of the page functionality, correctness and completeness of the voiced attributes (mainly role and aria- *).



  6. Checking forms in screen readers requires special attention. It is necessary to check the correctness of all text labels, errors and instructions, check the behavior of the form when sending successfully and if there are errors, the sequence and completeness of the information provided in the form filling mode (when switching between fields using TAB, and not in the page reading mode), correct focus moving etc.


Examples of the implementation of the available interfaces





Detailed WCAG AA compliance check



This section provides a WCAG checklist for AA level, grouped by relevant WCAG criteria. The list is based on http://webaim.org/standards/wcag/checklist . An official set of recommendations, a technician, and a list of common errors can be found at: https://www.w3.org/WAI/WCAG20/quickref/ .



All participants in the development and testing of the site are recommended to carefully study and master this list in order to make as few mistakes as possible at the development stage or correct them at the early stages. This will allow you to do the least effort in development and testing, as well as focus on testing for details that are important, but can be missed in the total number of errors.



1.1. Text version: provide a text version of any non-text content.



1.1.1. Non-textual content (Level A)





1.2. Media Content: Provide an Alternative Time-limited Media Content



In short, you should provide a decryption of the text of the recording, a text description of its contents or subtitles. If the video contains visual information that is not represented by sound, you should also provide an audio description for it.



If such content appears on the site, you should refer to the WCAG standard or, for example, the recommendations of Webaim .



1.3. Adaptability: create content that can be presented in various forms without losing data or structure



1.3.1. Information and Connectivity (Level A)





1.3.2. Significant reading sequence (Level A)





1.3.3. Sensory Characteristics (Level A)



If this is not an integral and inevitable part of the functionality:





1.4. Selectivity: simplify viewing and listening to content, separating the important parts from the secondary



1.4.1. Use color (Level A)





1.4.2. Sound Control (Level A)





1.4.3. Contrast (Level AA)





1.4.4. Resize text (Level AA)





1.4.5. Text on images (Level AA)





2.1. Keyboard accessibility



2.1.1. Keyboard (Level A)





2.1.2. Lack of focus traps (Level A)





2.2. Enough time: give users plenty of time to read and work with content.



2.2.1. Time setting (Level A)





2.2.2. Pause, stop, hide. (Level A)





The standard provides for exceptions to the rules if there is no technical capability or if animation or updating are key to the functionality of the page, and without them, the meaning or behavior of the page changes. Examples of exceptions with an explanation can be found in the explanatory notes for the criterion .



The criterion is quite strict, and full adherence to it can sometimes take a long time to develop and worsen the use of the page for ordinary users. It is necessary to seek a compromise between the strict formal requirements of the standard and reality in each case, but at the same time it is necessary to think about the interaction for each of the listed categories of users (see Introduction).



2.3. Do not use intentionally harmful design elements.



2.3.1. A limit of three or less flashes per second (Level A)





2.4. Navigation: provide users with assistance and support in navigating, searching for content and determining their current position on the site



2.4.1. Skip repeating blocks on all pages (Level A)





2.4.2. Page Title (Level A)





2.4.3. How to move the focus (Level A)





2.4.4. The purpose of the link (in context) (Level A)





2.4.5. Different search methods (Level AA)





2.4.6. (Level AA)





2.4.7. (Level AA)





3.1. :



3.1.1. (Level A)





3.1.2. (Level AA)





3.2.



3.2.1. (Level A)





3.2.2. (Level A)





3.2.3. (Level AA)





3.2.4. (Level AA)





3.3. :



3.3.1. (Level A)





3.3.2. (Level A)





3.3.3. (Level AA)





3.3.4. ( , ) (Level AA)



, , ( ), :





4.1. ,



4.1.1. (Level A)





4.1.2. , , , (Level A)





Afterword





')

Source: https://habr.com/ru/post/314910/

More articles:



All Articles