Skip to main content

Good practices for web developers

You can read more about this on the wordpress.org theme handbook, here - https://developer.wordpress.org/themes/functionality/accessibility/#headings

Headings#

It is important that heading tags are used logically rather than for any presentational or search engine optimisation (SEO) effect. A page containing twenty H1 headings might make for good, theoretical, SEO but it pretty much destroys the actual intended use of heading tags — to break a complex page down into sub-sections.

Images#

Some important rules regarding the alt attribute:

  • Be accurate and equivalent in presenting the same content and function of the image.
  • Be succinct. This means the correct content (if there is content) and function (if there is a function) of the image should be presented as succinctly as is appropriate. Typically no more than a few words are necessary, though rarely a short sentence or two may be appropriate.
  • NOT be redundant or provide the same information as text within the context of the image.
  • NOT use the phrases "image of ..." or "graphic of ..." to describe the image. It is usually apparent to the user that it is an image. And if the image is conveying content, it is typically not necessary that the user know that it is an image that is conveying the content, as opposed to text. If the fact that an image is a photograph or illustration, etc. is important content, it may be useful to include this in alternative text.

Forms#

Screen reader software may automatically toggle from a reading mode into an interactive, forms, mode as soon as a <form> tag is encountered. In this forms mode, the software may not render text that is not explicitly associated with a form control, so any text that uses plain <p></p> tags may be ignored. In order to extract all important information, screen reader users may need to make two passes at the form to extract all of the visual information — once in forms mode and then again in a reading mode. This represents a significant accessibility barrier.

Therefore, all forms — including the theme’s comment form — should ensure that all content within the <form></form> tags is explicitly associated to a form control via the <label> tag, its for attribute and an id attribute within the relevant input tag. Avoid the use of plain text (e.g .inside <p></p> tags) within the form block.

Post-submission responses — including any error messages — should always be perceivable. If possible, error messages should be generated at the top of the post-submission page so the user is immediately aware of any issues. Error messages should also make sense when read out of context.

Forms that only have a single input (such as a standard search form) may position the associated input label off screen in a manner that ensure the label text is available to screen reader users.

Focusable Elements* Such as input/a/buttons may not be the only elements that could receive focus when using keyboard to navigate. For a full list of elements you can check this table https://allyjs.io/data-tables/focusable.html