ACCESSIBILITY - DEVELOPERS FAQ ****************************** I SCREENREADERS 1. The desktop SR I am using for testing will not focus all of the content on the page when I navigate the page from top to bottom. Why? There are two common reasons for this. Incorrect SR use: Are you using the SRreen reader correctly? Both NVDA(Windows) and VoiceOver (macOS) can be used to either jump from one interactive element to another (similar to visual keyboard navigation with the tabulator key), or to navigate the page in the DOM order element by element, exposing all of the page content including passive text and images. For the latter use mode, which should be employed in testing, you MUST NOT use the tabulator (TAB) key. Instead, you must command the SR to advance element by element. On NVDA, you do this with the up/down arrow keys. On VO, you use VO+Right/Left arrow keys by default. NOTE: If the SR is in the Forms aka input mode (NVDA), or has delved inside a container (VO), you have to first return to the normal navigation mode before you can proceed along the page. To do this, on NVDA press ESR or NVDA+Space; on VO, press Shift+VO+Up Arrow or Shift + VO + Down Arrow to aSRend and deSRend (step by step) to/from a container. Aria-hidden: There may be content on your page that has been specifically hidden from assistive technology. Look for elements with aria-hidden=true attributes. If the content should be exposed to assistive technology, remove the aria-hidden attribute. II WORKING WITH CONTENT 1. Where do I place the aria-expanded attribute on a menu, accordion, pop-up, etc? Place the attribute on the element that triggers something to open and close. Do not place it inside the content being opened. That is, use:
NOT:
Also, remember that you must update the attribute value in code whenever the content opens or closes. It will not auto update in response to changes to the DOM. It is only a passive descriptor. 2. How do I hide content from assistive technology without hiding it visually or removing it from the page? Use the aria-hidden=true attribute. The DOM tree inside the element, and the element itself, will be made non-existing and inaccessible to screenreaders. Note: You cannot make an element unfocusable to keyboard users (navigating the web page with the tabulator key) by using aria-hidden. The attribute only affects assistive technology, and keyboard navigation is not a form of assistive technology. 3. How do I make an element focusable or unfocusable for keyboard users? Use the tabindex attribute. Tabindex=0 will mark the element as part of the page tab order. It can then be tabbed into with a keyboard. Tabindex-1, in turn, will make the element unfocusable for keyboard users. Tabindex=-1 elements can still be programmatically focused (e.g. by Javascript HTMLElement.focus() method). They can also be focused by screen readers. To make content only available to pointer device users (mouse, touch), use both tabindex=-1 and aria-hidden=true together. 4. What is the difference between ALT="" and aria-hidden=true? The ALT attribute is used on tags. When the attribute has an empty string or has no value, assistive technology hides the image as if it did not exist on the page. Aria-hidden, unlike ALT, can be used with any tag. An tag can, of course, contain both attributes. In some situations, this can be useful. For example, an image can be hidden from screen readers without having to give it an empty ALT text. Visit our sponsor SomeCompany Here, the image alt is shown to visual users in case the image fails to load (pointing at an external resource, perhaps), but screen reader users will not perceive the image due to its aria-hidden status. This is done because the logo image has no informative purpose and is aimed only at visual users. Removing unnecessary parts makes the link easier to comprehend for a screen reader user. One could also write: Visit our sponsor: SomeCompany This, too, hides the image from screen readers, but will not display ALT for text-only browser users or when the image fails to load. That is, the image is treated as decorative. Both methods are sound. The choice between the two is a service design decision. 5. I use the tag for images, but screenreaders will not read the ALT attribute. How do I solve this? The ALT attribute can only be used with the tag. On , you can use the following attributes to provide an accessible name for screen readers: - role=img - aria-label=The image ALT 6. How do screen readers regard CSS display:none and CSS visibility:hidden? Visually, both methods remove content from the web page, yet are not interchangeable: Visibility:hidden elements will retain their space on the page as if they were only made inactive and transparent whereas display:none elements are altogether removed from the page. Screenreaders, however, will treat both definitions similarly: Content marked with either property will be completely hidden from the user when they navigate the page. Note that aria-labelledby and aria-describedby can still reference hidden content. 7. What do I need to take into account when embedding content as frames? Frames have to be named (WCAG 1.3.1). The correct way to do this is with a title attribute:
. Otherwise, some accessibility checkers will complain that the page features content which lies without a landmarked region. Users are little affected by that issue, though. 2. My links have an icon attached to them designating them as external links or links that open a specific kind of a document. How do I define the anchor tag so that screen reader users understand it correctly? A number of methods are available. Below is a simple technique employed on the demo page. Using aria-label: A similar result can be achieved by employing a visually hidden extension to the link text, which a screen reader exposes, as it will not heed CSS styling: (Link points outside this web site). Rationale: - The icon has an empty ALT to conceal it from screen readers. The user in this case need not be described that there is an image attached to the link, since the image is only a visual indicator aimed at visual users. - Instead, the link as a whole has an aria-label (approach 1), which defines how the link Is described to assistive technology. That the link has a non-standard role, is told in the aria label. Hence, the icon is now unnecessary for screen readers. - Similarly, the second approach appends the non-standard role description to the link text. Now, it is unnecessary to repeat that description in the image element. - The benefit here is that the link is made atomic: There is a single link with a single description, even though technically the link comprises two parts (text and image). This has implications on how assistive technology describes the link; see below. Compare: Let us use the following (very logical) code instead: Here, the icon has an ALT text describing the information it conveys. Hence, the link is described in two parts in much the same way it is perceived visually. This makes a lot of sense and is correct. However, from this definition follows that some screen readers will faithfully expose the link as comprising two different elements - Siteimprove and External link - because there is both a link text and an image element. While this is perfectly fine from WCAG point of view, in practice users may find a link described in this fashion less easy to understand when they navigate the page element by element. The reason is that some screen readers will only announce the first link part when the link is focused in element-by-element navigation. The second part, the image and its ALT about an external status, is, correspondingly, announced only after the user navigates forward along the page. This, in turn, usually happens after the user has already decided whether to click the link or not, as they cannot, of course, see ahead and know that the link still continues. That, however, has to do with the fashion in which some screenreaders work and is not the fault of the developer. Technically, the link is correctly defined. The latter method, that of using the image ALT, is therefore OK, but the author of this FAQ prefers the first two approaches with either a tailored link text or an aria-label, given their unambiguity to the user. 3. I need to place a link to a list of references in a text paragraph. How do I describe the link to assistive technology? In a situation similar to the below: This is a text paragraph. Here lies a sentence that will feature an anchor link pointing at a reference [1]. (At the bottom of the text/page)[1] Article XYZ, Author, 2020. Available online: Link to article[2] Keynote at a webinar XYZ, Speaker, Event, 2020. Link to a recording.[3] ... You can define the reference link in the paragraph like so: [1] That is, you can systematically inject an aria-label with the prefix Reference (or similar) and e.g. the title of the reference (spliced off the first comma, etc.) as the links description. This will be more informative to the assistive technology users than mere [1], and is easy enough to automate. IV SINGLE PAGE APPLICATIONS 1. How can I make screenreaders announce a new page title when I update the title tag to reflect a change in the page context in my SPA? Please see the SPA Guide for implementation ideas. V TAILOR-BUILT WEB PAGE ELEMENTS 1. What is the difference between