What have HTML5 elements ever done for Accessibility

Slide 1

Slide 1 text

Coolfields Consulting What have the Romans ever done for us? HTML5 elements

Slide 2

Slide 2 text

Coolfields Consulting What Have the HTML5 Elements Ever Done for Accessibility? Graham Armfield Web Accessibility Consultant WordPress Developer graham.armfield@coolfields.co.uk @coolfields

Slide 3

Slide 3 text

A bit about me 3 I’m a… • Web Accessibility Consultant • WordPress Developer Photo by Mike Pead @coolfields

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Semantic sectioning elements , , , , , ,

Slide 7

Slide 7 text

History of page layouts - part 1

Slide 8

Slide 8 text

History of page layouts - part 2

Slide 9

Slide 9 text

History of page layouts - part 3

Slide 10

Slide 10 text

History of page layouts - part 4

Slide 11

Slide 11 text

History of page layouts - part 5

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

HTML5 landmarks , , are always landmarks , are landmarks… but only if they are not inside , , , , or , are landmarks… if labelled using aria-label or aria-labelledby

Slide 14

Slide 14 text

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/

Slide 15

Slide 15 text

HTML5 landmarks

Slide 16

Slide 16 text

Associating captions with images and

Slide 17

Slide 17 text

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.

Looking west...

Slide 18

Slide 18 text

WordPress and HTML5 support The idea is to link the caption to the image (or whatever else is contained in the element. But does this buy us anything? https://developer.wordpress.org/reference/functions/add_theme_supp ort/

Slide 19

Slide 19 text

and Accessibility support: My recent screen reader survey shows there is little support for being programmatically linked to . 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...

Slide 20

Slide 20 text

and 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/

Slide 21

Slide 21 text

Native dialog boxes

Slide 22

Slide 22 text

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 was minted for.

Slide 23

Slide 23 text

Using - the theory Some content Use javascript to open (and close) modal… myDialog.showModal(); …triggered by buttons. In Chrome on Windows 10

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

New HTML5 input types input type="number", "tel", "url", "email", "date"

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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"

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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"

Slide 36

Slide 36 text

input type="date" Chrome on Android phone Chrome on Windows 10

Slide 37

Slide 37 text

input type="date" IE11 on Windows 10 Safari on Mac

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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/

Slide 40

Slide 40 text

A native combobox

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

Using - the code Towns in Surrey …

Slide 43

Slide 43 text

Using - typical UI Chrome on Windows 10

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

- 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

Slide 47

Slide 47 text

A native accordion and

Slide 48

Slide 48 text

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.

Slide 49

Slide 49 text

Using and System Requirements

Requires a computer running an operating system. The computer must have some memory and ideally some kind of long-term storage.

Chrome on Windows 10 - collapsed Chrome on Windows 10 - expanded

Slide 50

Slide 50 text

and Browser support: Generally very good in all modern browsers. No support on IE11 or Edge, but polyfills are available. Some bugs in Android if contains a Styling (including arrows) is possible.

Slide 51

Slide 51 text

and 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

Slide 52

Slide 52 text

and 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:

Hard disk capacity

Different size capacities of hard disk are available …

Slide 53

Slide 53 text

So what have these HTML5 elements done for Accessibility?

Slide 54

Slide 54 text

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?

Slide 55

Slide 55 text

Act now for better support…

Slide 56

Slide 56 text

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/

Slide 57

Slide 57 text

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/

Slide 58

Slide 58 text

Thanks for listening Any questions? graham.armfield@coolfields.co.uk @coolfields