Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What have HTML5 elements ever done for Accessib...

What have HTML5 elements ever done for Accessibility

Ten years ago, the HTML5 spec introduced many new elements and input types.

But how well are they actually supported by browsers, and more importantly assistive technologies such as screen readers and voice recognition software.

I've been researching browser and accessibility support for some of the new HTML5 elements and this talk presents my findings.

[Spoiler alert] - It's not all good news...

Coolfields Consulting

May 19, 2019
Tweet

Other Decks in Technology

Transcript

  1. Coolfields Consulting What Have the HTML5 Elements Ever Done for

    Accessibility? Graham Armfield Web Accessibility Consultant WordPress Developer [email protected] @coolfields
  2. A bit about me 3 I’m a… • Web Accessibility

    Consultant • WordPress Developer Photo by Mike Pead @coolfields
  3. What I'm going to cover A survey of some of

    the newer HTML5 elements, and how they can help with accessibility. Featuring: • Semantic sectioning elements • Dialog boxes • New input types • Other form-related elements • Native accordions
  4. Accessibility requirements To be considered accessible, each of the elements

    must support all these users: • Mouse users • Touch users • Keyboard users • Screen reader users • Voice recognition users
  5. History of page layouts - part 1 <FRAME /> <FRAME

    /> <FRAME /> <FRAME /> <FRAME /> <FRAMESET ROWS="100,70,*,70"> </FRAMESET> <FRAMESET COLS="70%,30%> </FRAMESET>
  6. History of page layouts - part 2 <tr><td colspan="2"></td></tr> <tr><td

    colspan="2"></td></tr> <tr><td colspan="2"></td></tr> <tr> <td width="650"></td> <td width="350"> </td> </tr> <table> </table>
  7. History of page layouts - part 4 <div role="banner"> <div

    role="navigation"> <div role="contentinfo"> <div role="main"> <div role= "complementary">
  8. Sectional HTML5 elements Yes, they can be used as styling

    hooks. But they are semantic elements that annotate regions of the page. And in some situations they become landmarks - used by screen reader users to allow them to jump from region to region within a page.
  9. HTML5 landmarks <main>, <nav>, <aside> are always landmarks <header>, <footer>

    are landmarks… but only if they are not inside <main>, <article>, <aside>, <nav>, or <section> <section>, <article> are landmarks… if labelled using aria-label or aria-labelledby
  10. Accessibility support Pretty universal - even when using IE11 with

    JAWS screen reader. Recommendation: Go ahead and use them (properly) – they enhance accessibility. Can be even better when used with aria-label: https://openinclusion.com/blog/making-the-most-of-landmark- roles/
  11. Using captions in WordPress Captions are physically adjacent to images,

    but screen reader users won't necessarily know if they are associated with the image. <div id="..." class="wp-caption alignnone"> <img class="size-large" src="" alt="Bristol..."> <p class="wp-caption-text">Looking west...</p> </div>
  12. WordPress and HTML5 support The idea is to link the

    caption to the image (or whatever else is contained in the <figure> element. But does this buy us anything? https://developer.wordpress.org/reference/functions/add_theme_supp ort/
  13. <figure> and <figcaption> Accessibility support: My recent screen reader survey

    shows there is little support for <figcaption> being programmatically linked to <figure>. Good news though - the pattern does not spoil accessibility. So it's OK to use the pattern. And maybe one day screen readers will catch up...
  14. <figure> and <figcaption> Recommendation: Use it by all means, but

    don't rely on it giving screen reader users anything extra. Always set appropriate alternate text on the image itself. See blog post: https://www.hassellinclusion.com/blog/figure- figcaption-extended-alternate-text-screen-readers/
  15. Getting modal dialogs right Modals can be a challenge for

    accessibility: • Need to control keyboard focus when dialog opens. • Need to constrain focus in the modal. • Need to replace focus when modal closes. There are accessible patterns, but they rely on javascript updates to pages, and some ARIA. A native modal element would be useful, and would standardise user experience across the web. This is what <dialog> was minted for.
  16. Using <dialog> - the theory <dialog> Some content </dialog> Use

    javascript to open (and close) modal… myDialog.showModal(); …triggered by buttons. In Chrome on Windows 10
  17. <dialog> Browser support: Only Blink-based browsers - ie Chrome, Opera,

    maybe the new Edge? Doesn't work at all in Firefox or Safari or IE11. Long dialogs - scrolling scrolls the entire page. Can be tricky to style. There are rumours that it will soon be removed from the HTML spec.
  18. <dialog> Accessibility support: In Chrome, by default, focus goes to

    first tabable element in the dialog – which may of course be right at the bottom. Returning focus to element that opened dialog does not work. No announcement of dialog role in any screen reader.
  19. <dialog> can I use it? Recommendation: Even with polyfills, it's

    not ready for production sites. Some resources: https://developer.paciellogroup.com/blog/2018/06/the-current- state-of-modal-dialog-accessibility/ https://www.scottohara.me/blog/2019/03/05/open-dialog.html
  20. input type="number", "tel" The theory: Easier for users to get

    the format for the input correct. On mobile devices, these two should trigger (slightly different) numeric keyboards. Also, can trigger browser validation - including in desktop browsers input type="number" on Android phone
  21. input type="number", "tel" Browser support: Does what's expected on iOS

    and Android devices. Desktop/laptop shows spinner in "number" input field (not in IE11 though). Accessibility support: Browser error messages may not be read out by screen readers. Recommendation: Use, but with your own custom validation.
  22. input type="url" and "email" The theory: Making it easier for

    user to enter correct format by bringing appropriate symbols and case into mobile keyboard. • type="url" shows '/' and 'www.', etc • type="email" shows '@' and '.com', etc Chrome on Android phone
  23. Browser support: Does what's expected on iOS and Android devices.

    All desktop browsers (including IE11) trigger browser validation on format, and will show error messages onscreen. But the format may not be what you are looking for. input type="url" and "email"
  24. input type="url" and "email" Accessibility support: Browser validation messages could

    be more informative. Some screen readers voice error messages, and also some tell user that input is invalid. But, whilst validation messages are shown, they are not read out by JAWS screen reader.
  25. input type="url" and "email" Recommendation: Good for convenience of appropriate

    symbols, but needs more controlled validation error messages. And error messages that are voiced by all screen readers. So, override browser validation with your own more informative custom validation messages. Always specify required format in the <label> element.
  26. input type="date" The theory: On mobile devices, type="date" can bring

    up the native date picker - which provides a familiar and accessible experience. On desktop/laptops user can get a fully accessible date picker, but without being forced to use it.
  27. Browser support: Does what's expected on iOS and Android devices.

    Good support in Firefox and Chrome. Support includes default dates, and max and min dates. Not surprisingly, no support in IE11. But more surprisingly, no support in Safari on Macs. input type="date"
  28. input type="date" Accessibility support: IE11 + Safari/Mac interface obviously gives

    user a poor experience. Browser error messages not read out by some screen readers. Screen reader users have difficulty finding previously selected date in some combinations. Very difficult to use with Dragon NaturallySpeaking.
  29. input type="date" Recommendation: Cannot be used in production to give

    a good accessible or user- friendly experience. https://www.hassellinclusion.com/blog/collecting-dates- accessible/ https://www.hassellinclusion.com/blog/input-type-date-ready- for-use/
  30. Getting combo-boxes right Combo-boxes can be a really useful timesaver

    for users. Allows users to type a couple of characters to show a list of options - one of which can be chosen. But user can still type their own entry if required. Can be tricky to get a fully accessible example.
  31. Using <datalist> - the code <label for="towns">Towns in Surrey</label> <input

    id="towns" name="towns" type="text" list="suggestions"> <datalist id="suggestions"> <option value="Byfleet"> <option value="Camberly"> <option value="Chobham"> <option value="Farnham"> <option value="Guildford"> … </datalist>
  32. <datalist> Browser support: OK in Chrome. Android support is OK.

    No support in Safari, neither on iOS nor Mac. Some bugs in IE11 and Edge. In Firefox it only works on input type="text".
  33. <datalist> Accessibility support (where browser support present): Keyboard functionality is

    pretty good. Not all screen readers announce the role, and/or the presence of options - so users don't know they are there. Not all screen readers announce number of options. Doesn't work at all well with JAWS.
  34. <datalist> - can we use it? Recommendation: Lack of support

    in some modern browsers, and JAWS screen reader means it cannot be used in production to provide an accessible experience. So best to stick with the accessible W3C combo-box model. https://www.w3.org/TR/wai-aria-practices- 1.1/examples/combobox/aria1.0pattern/combobox- autocomplete-both.html
  35. Getting accordions right Accordions are a useful way of saving

    space on a page. Can be used in FAQ pages for example, or in mobile views. But it's important to make them accessible to keyboard users, screen reader users, and voice recognition software users. A native accordion would be useful and could standardise a good user experience across the web.
  36. Using <summary> and <details> <details> <summary>System Requirements</summary> <p>Requires a computer

    running an operating system. The computer must have some memory and ideally some kind of long-term storage. </p> </details> Chrome on Windows 10 - collapsed Chrome on Windows 10 - expanded
  37. <summary> and <details> Browser support: Generally very good in all

    modern browsers. No support on IE11 or Edge, but polyfills are available. Some bugs in Android if <details> contains a <select> Styling (including arrows) is possible.
  38. <summary> and <details> Accessibility support: Good keyboard support. Good voice

    recognition support. Good screen reader support - except NVDA/Firefox announcing expanding/collapsing. With a suitable polyfill it can be perfect… https://wet-boew.github.io/wet-boew/demos/details/details- en.html
  39. <summary> and <details> Recommendation: Add in the polyfill and we're

    good to go. Add in a header to make it easier for screen reader users to find the sections: <details> <summary> <h3>Hard disk capacity</h3></summary> <p>Different size capacities of hard disk are available …</p> </details>
  40. We've been let down? HTML5 elements can provide a standardised

    and accessible experience for everyone - providing they're implemented correctly. But browser and assistive technology vendors have been slow to embrace some of the new HTML5 elements. "If no-one is using them, where's the incentive?" The problem is - if it's not possible to use them in an accessible way, how can we use them?
  41. Reporting defects - 1 Google Chromium, Android and Talkback https://bugs.chromium.org/p/chromium/issues/list

    Apple for Safari and Voiceover https://developer.apple.com/bug-reporting/ Firefox https://bugzilla.mozilla.org/home MS Edge https://developer.microsoft.com/en-us/microsoft- edge/platform/issues/