Essential HTML tweaks for accessible themes

Talk by Martin Stehle / View Slides

The short talk shows developers, theme authors and plugin authors how to write the Hypertext Markup Language (HTML) code of themes and plugins for meeting the Web Content Accessibility Guidelines (WCAG) 2.1.

There are important success criteria in the WCAG which affect the way how you write the HTML code for your users. Do you know which ones? And do you know which functions are provided by the WordPress core to fullfill those criteria? This talk shows them all.

The talk provides you the tricks about

  • how to approach the challenge of writing accessible HTML code in an easy and effective way,
  • how to set informations and relationships of the content,
  • how to establish a meaningful sequence of the content,
  • how to write alternatives for non-text contents.

In detail you can learn about the WCAG-compliant generation of e.g.

  • continuous texts,
  • forms on WordPress options pages,
  • tables.

Questions on “Essential HTML tweaks for accessible themes

  1. Q: Since the title element can only contain text, would you recommend avoiding language changes in page titles, or using different text for the title element and the main page heading?

    1. Yes, I recommend to avoid language changes in the title element to stay comprehensible for all users (and also accessible). Instead use the language of the website, even in the title of the page content, and use the foreign text in the rest of the content.

  2. Q: WordPress doesn’t provide any native tools for making forms; but they’re clearly needed by most sites. Do you have a recommended form plugin for WordPress?

    1. My opinion is: a length of 60 – 70 characters is sufficient. Think about a list of posts with fatured images, and all these images have an alt text. Short texts help to scan that list quickly. I’d use “very lengthy” alt texts as image captions.

    1. A very bad example is any element with the “onclick” event. Use the A element instead.
      Bad examples of Javascript interactivity are often found in forms when Javascript events like “onchange” and “onsubmit” trigger changes which an assistive technology is not aware of and so the user, too., E.g. loading a new page after an option in a selection field was selected.
      A good example is: first develop without Javascript. If that work, you can add Javascript interactivity as long as assistive technologies (and so the users) aree awre of the changes created by Javascript. That approach is also known as “Progressive enhancement”.

  3. A very bad example is any element with the “onclick” event. Use the A element instead.
    Bad examples of Javascript interactivity are often found in forms when Javascript events like “onchange” and “onsubmit” trigger changes which an assistive technology is not aware of and so the user, too., E.g. loading a new page after an option in a selection field was selected.
    A good example is: first develop without Javascript. If that work, you can add Javascript interactivity as long as assistive technologies (and so the users) aree awre of the changes created by Javascript. That approach is also known as “Progressive enhancement”.