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
   

   View Slide

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
   

   View Slide

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

   View Slide

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
   

   View Slide

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
   

   View Slide

6. Semantic sectioning elements
   , , ,
   , ,
   ,
   

   View Slide

7. History of page layouts - part 1
   
   
   
   
   
   
   

   View Slide

8. History of page layouts - part 2
   
   
   
   
   
   
   
   
   
   
   

   View Slide

9. History of page layouts - part 3
   
   
   
   
   

   View Slide

10. History of page layouts - part 4
    
    
    
    "complementary">
    

    View Slide

11. History of page layouts - part 5
    
    
    
    
    

    View Slide

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.
    

    View Slide

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

    View Slide

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/
    

    View Slide

15. HTML5 landmarks
    

    View Slide

16. Associating captions with images
    and
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. Native dialog boxes
    
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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"
    

    View Slide

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.
    

    View Slide

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

    View Slide

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.
    

    View Slide

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"
    

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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/
    

    View Slide

40. A native combobox
    
    

    View Slide

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.
    

    View Slide

42. Using - the code
    Towns in Surrey
    list="suggestions">
    
    
    
    
    
    
    …
    
    

    View Slide

43. Using - typical UI
    Chrome on Windows 10
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

47. A native accordion
    and
    

    View Slide

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.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

53. So what have these HTML5
    elements done for Accessibility?
    

    View Slide

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?
    

    View Slide

55. Act now for better support…
    

    View Slide

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/
    

    View Slide

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/
    

    View Slide

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

    View Slide