Revision 1130919 of Handling common accessibility problems

<div>{{draft}}{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}</div>

<p class="summary">Next we turn our attention to accessibility, providing information on common problems, how to do simple testing, and how to make use of auditing/automation tools for finding accessibility issues.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Prerequisites:</th>
   <td>Familiarity with the core <a href="/en-US/docs/Learn/HTML">HTML</a>, <a href="/en-US/docs/Learn/CSS">CSS</a>, and <a href="/en-US/docs/Learn/JavaScript">JavaScript</a> languages; an idea of the high level <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Introduction">principles of cross browser testing</a>.</td>
  </tr>
  <tr>
   <th scope="row">Objective:</th>
   <td>To be able to diagnose common Accessibility problems, and use appropriate tools and techniques to fix them.</td>
  </tr>
 </tbody>
</table>

<h2 id="What_is_accessibility">What is accessibility?</h2>

<p>When we say accessibility in the context of web technology, most people immediately think of making sure websites/apps are usable by people with disabilities, for example:</p>

<ul>
 <li>Visually impaired people using screen readers or magnification/zoom to access text</li>
 <li>People with motor function impairments using the keyboard (or other non-mouse features) to activate website functionality.</li>
 <li>People with hearing impairments relying on captions/subtitles or other text alternatives for audio/video content.</li>
</ul>

<p>However, it is wrong to say that accessibility is just about disabilities. Really, the aim of accessibility is to make your websites/apps are usable by as many people in as many contexts as possible, not just those users using high-powered desktop computers. Extreme examples might include:</p>

<ul>
 <li>Users on mobile devices.</li>
 <li>Users on alternative browsing devices such as TVs, watches, etc.</li>
 <li>Users of older devices that might not have the latest browsers.</li>
 <li>Users of lower spec devices that might have slow processors.</li>
</ul>

<p>In a way, this whole module is about accessibility — cross browser testing makes sure that your sites can be used by as many people as possible.</p>

<p>That said, this article will cover cross browser and testing issues surrounding people with disabilities, and how they use the Web. We've already talked about other spheres such as <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS#Responsive_design_problems">responsive design</a> and <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/JavaScript#Performance_issues">performance</a> in other places in the module.</p>

<div class="note">
<p><strong>Note</strong>: Like many things in web development, accessibility isn't about 100% success or not; 100% accessibility is pretty much impossible to achieve for all content, especially as sites get more complex. Instead, it is more about making an effort to make as much of your content accessible to as many people as possible, via defensive coding, and sticking to best practices.</p>
</div>

<h2 id="Quick_tests">Quick tests</h2>

<p>In this section we'll detail some of the main issues that arise around web accessibility, connected with specific technologies.</p>

<h3>An aside on web accessibility guidelines and laws</h3>

<p>There are numerous checklists and sets of guidelines available for basing accessibility tests on, which might seem overwhelming at first glance. Our advice is to familiarise yourself with the basic areas in which you need to take care, as well as understanding the high level structures of the guidelines that are most relevant to you.</p>

<ul>
 <li>For a start, the W3C has published a large and very detailed document that includes very precise, technology-agnostic criteria for accessibility conformance. These are called the <a href="https://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines</a> (WCAG), and they are not a short read by any means. The criteria are spit up into four main categories, which specify how implementations can be made perceivable, operable, understandable, and robust. The best place to get a light introduction and start learning is <a href="https://www.w3.org/WAI/WCAG20/glance/Overview.html">WCAG at a Glance</a>. There is no need to learn WCAG off by heart — be aware of the major areas of concern, and use a variety of techniques and tools to highlight any areas that don't conform to the WCAG criteria (see below for more).</li>
 <li>Your country may also have specific legislation governing the need for websites serving their population to be accessible — for example <a href="https://www.section508.gov/content/learn">Section 508 of the Rehabilitation Act</a> in the US,&nbsp;<a href="https://www.einfach-fuer-alle.de/artikel/bitv_english/">Federal Ordinance on Barrier-Free Information Technology</a> in Germany, the <a href="https://www.legislation.gov.uk/ukpga/2010/15/contents">Equality Act</a> in the UK,&nbsp;<a href="https://www.agid.gov.it/agenda-digitale/pubblica-amministrazione/accessibilita">Accessibilità</a> in Italy, the <a href="https://www.humanrights.gov.au/world-wide-web-access-disability-discrimination-act-advisory-notes-ver-41-2014">Disability Discrimination Act</a> in Australia, etc.</li>
</ul>

<p>So while the WCAG is a set of guidelines, your country will probably have laws governing web accessibility, or at least the accessibility of services available to the public (which could include websites, television, physical spaces, etc.) It is a good idea to find out what your laws are. If you make no effort to check that your content is accessible, you could possibly be in trouble with the law if people with diabilities complain about it.</p>

<p>This sounds serious, but really you just need to consider accessibility as a main priority of your web development practices:</p>

<ul>
 <li>Consider accessibility from the start of a project, and test early and often. Just like any other bug, an accessibility problem becomes more expensive to fix the later it is discovered.</li>
 <li>Bear in mind that a lot of accessibility best practices benefit everyone, not just users with disabilities. For example, lean semantic markup is not only good for screen readers, it is also fast to load and performant, so better for everyone, especially those on mobile devices, and/or slow conections.</li>
 <li>Publish an accessibility statement on your site, which details what your policy is towards accessibility, and what steps you have taken towards making the site accessible.</li>
 <li>If someone does complain that your site has an accessibility problem, start a dialog with them and show them that you care. Take reasonable steps to try to fix the problem.</li>
</ul>

<h3>HTML</h3>

<p>Semantic HTML (where the elements are used for their correct purpose) is accessibile right out of the box — such content is readable by sighted viewers (provided you don't do anything silly like make the text way too small or hide it using CSS), but will also be usable by assistive technologies like screen readers: apps that literally read out a web page to their user.</p>

<h4>Semantic structure</h4>

<p>The most important quick win in semantic HTML is to use a structure of headings and paragraphs for your content; this is because screen reader users tend to use the headings of a document as signposts to find the content they need more quickly. If your content has no headings, all they will get is a huge wall of text with no signposts to find anything. Examples of bad and good HTML:</p>

<pre class="brush: html example-bad">
&lt;font size="7"&gt;My heading&lt;/font&gt;
&lt;br&gt;&lt;br&gt;
This is the first section of my document.
&lt;br&gt;&lt;br&gt;
I'll add another paragraph here too.
&lt;br&gt;&lt;br&gt;
&lt;font size="5"&gt;My subheading&lt;/font&gt;
&lt;br&gt;&lt;br&gt;
This is the first subsection of my document. I'd love people to be able to find this content!
&lt;br&gt;&lt;br&gt;
&lt;font size="5"&gt;My 2nd subheading&lt;/font&gt;
&lt;br&gt;&lt;br&gt;
This is the second subsection of my content. I think is more interesting than the last one.</pre>

<pre class="brush: html example-good">
&lt;h1&gt;My heading&lt;/h1&gt;

&lt;p&gt;This is the first section of my document.&lt;/p&gt;

&lt;p&gt;I'll add another paragraph here too.&lt;/p&gt;

&lt;h2&gt;My subheading&lt;/h2&gt;

&lt;p&gt;This is the first subsection of my document. I'd love people to be able to find this content!&lt;/p&gt;

&lt;h2&gt;My 2nd subheading&lt;/h2&gt;

&lt;p&gt;This is the second subsection of my content. I think is more interesting than the last one.&lt;/p&gt;</pre>

<p>In addition, your content should make logical sense in its source order — you can always place it where you want using CSS later on, but you should get the source order right to start with.</p>

<p>As a test, you can turn off a site's CSS and see how understandable it is without it. You could do this manually by just removing the CSS from your code, but the easiest way is to use browser features, for example:</p>

<ul>
 <li>Firefox: Select <em>View &gt; Page Style &gt; No Style</em> from the main menu.</li>
 <li>Safari: Select <em>Develop &gt; Disable Styles</em> from the main menu (to enable the <em>Develop</em> menu, choose <em>Safari&nbsp;&gt; Preferences &gt; Advanced &gt; Show Develop menu in menu bar</em>).</li>
 <li>Chrome: Install the Web Developer Toolbar extension, then restart the browser. Click the gear icon that will appear, then select <em>CSS &gt; Disable All Styles</em>.</li>
 <li>Edge: Select&nbsp;<em>View &gt; Style &gt; No Style</em> from the main menu.</li>
</ul>

<h4>Using native keyboard accessibility</h4>

<p>Certain HTML features can be selected using only the keyboard — this is default behavior, available since the early days of the web.</p>

<h4>Building in keyboard accessibility</h4>

<h4>Text alternatives</h4>

<h4>Element relationships</h4>

<p>quick tests like viewing the site without CSS and tabbing through the page with a keyboard.<br />
 Cheap screen reader testing options like Apple’s Voiceover and ChromeVox. NVDA also good</p>

<p>user testing important, a11y audits worth considering.</p>

<p>speech recognition like dragon naturally speaking<br />
 Recommendations to include keyboard tests in automated testing.<br />
 Auditing tools like tenon.io and wave.webaim.org. https://khan.github.io/tota11y/ also good.<br />
 Automated tools like aXe.</p>

<p>JS problems, ARIA?</p>

<p>XXX</p>

<h2 id="Finding_help">Finding help</h2>

<p>There are many other issues you'll encounter with Accessibility; the most important thing to know really is how to find answers online. Consult the HTML and CSS article's <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS#Finding_help">Finding help section</a> for some good pointers.</p>

<h2 id="Summary">Summary</h2>

<p>XXX</p>

<p>{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}</p>