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...

Transcript

1. Coolfields Consulting What have the Romans ever done for us? HTML5 elements
2. Coolfields Consulting What Have the HTML5 Elements Ever Done for Accessibility? Graham Armfield Web Accessibility Consultant WordPress Developer graham.armfield@coolfields.co.uk @coolfields
3. A bit about me 3 I’m a… • Web Accessibility Consultant • WordPress Developer Photo by Mike Pead @coolfields
4. 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
5. 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
6. Semantic sectioning elements <header>, <footer>, <nav>, <main>, <section>, <article>, <aside>
7. History of page layouts - part 1 <FRAME /> <FRAME /> <FRAME /> <FRAME /> <FRAME /> <FRAMESET ROWS="100,70,*,70"> </FRAMESET> <FRAMESET COLS="70%,30%> </FRAMESET>
8. 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>
9. History of page layouts - part 3 <div> <div> <div> <div> <div>
10. History of page layouts - part 4 <div role="banner"> <div role="navigation"> <div role="contentinfo"> <div role="main"> <div role= "complementary">
11. History of page layouts - part 5 <header> <nav> <footer> <main> <aside>
12. 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.
13. 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
14. 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/
15. HTML5 landmarks
16. Associating captions with images <figure> and <figcaption>
17. 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>
18. 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/
19. <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...
20. <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/
21. Native dialog boxes <dialog>
22. 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.
23. 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
24. <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.
25. <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.
26. <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
27. New HTML5 input types input type="number", "tel", "url", "email", "date"
28. 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
29. 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.
30. 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
31. 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"
32. 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.
33. 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.
34. 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.
35. 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"
36. input type="date" Chrome on Android phone Chrome on Windows 10
37. input type="date" IE11 on Windows 10 Safari on Mac
38. 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.
39. 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/
40. A native combobox <datalist>
41. 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.
42. 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>
43. Using <datalist> - typical UI Chrome on Windows 10
44. <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".
45. <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.
46. <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
47. A native accordion <summary> and <details>
48. 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.
49. 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
50. <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.
51. <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
52. <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>
53. So what have these HTML5 elements done for Accessibility?
54. 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?
55. Act now for better support…
56. 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/
57. Reporting defects - 2 NVDA https://github.com/nvaccess/nvda/issues JAWS https://github.com/FreedomScientific/VFO-standards- support/issues Dragon NaturallySpeaking - chat support https://www.dragonsupportservice.us/services/
58. Thanks for listening Any questions? graham.armfield@coolfields.co.uk @coolfields