WordPress is used by over 20% of the world's websites. But how many accessible themes are there in the WordPress theme repository?
The answer is, "not many".
This presentation tries to demystify the recently introduced accessibility-ready tag within the theme review process. It's a tag that WordPress theme authors can use to indicate that their theme has good accessibility features. It's actually not that hard to achieve, and the web will be a better place if there were more accessibility-ready themes for people to choose from.
I also look at the impact WordCamp plugins can have on accessibility, and talk about whether the accessibility-ready principles could be used by plugin authors. The short answer, is that yes they can be useful.
6. Why accessibility is important
• More people than you think have disabilities or
impairments
• Populations are growing older
• Those two groups combined have significant spending
power
• There are legal frameworks
• And, morally it’s the right thing to do
6
12. Why 'accessibility-ready'?
• A website's accessibility is not just down to the theme.
• Admins add plugins…
• Then they let content authors loose on it…
12
13. How many accessible themes?
13
3,048 themes in repository (as
at 23rd February 2015)
9 results for 'accessibility'
and
13 results for 'accessible'
and
32 have 'accessibility-ready' tag
14. An accessible theme author writes…
14
http://davidakennedy.com/2014/07/08/accessible-wordpress-theme-lessons/
15. The 'accessibility-ready' sections:
Required
• Headings
• ARIA landmarks
• Link text
• Controls
• Keyboard navigation
• Colour contrast
• Skip links
• Forms
• Images
• Media
15
Recommended
• Zoomable text
• Removal of title attributes
Not Allowed
• tabindex
• accesskey
• Popups without warning
16. Headings
• semantic elements – not
just for presentation
• must use a 'reasonable' html heading structure
• subsections defined by theme must use headings – eg
widget titles, post titles, etc
16
19. Controls
• anything that behaves like a button or a link should be
marked up appropriately
ie <button> or <a> or <input>
• these elements need machine-readable text to indicate
what they are for
• dashicons (or similar) on their own are not enough
19
20. Keyboard
navigation
• keyboard focus must be
visible everywhere
• dropdown menus
• intuitive (tab order)
• tabindex? – use only 0 or -1
• accesskey – do not use
20
27. Zoomable Text
• in the recommended list
• zooming and resizing are not the same thing
27
28. Removal of title
Attributes
• title attributes have been
historically used in many
places to provide 'tool tip'
functionality
• but in terms of accessibility, their use is never the right
answer
28
30. So what about plugins?
• There is a plugin review process.
• But no mention of accessibility.
• Could there be an accessibility review?
• Should there be?
30
31. Can plugins affect accessibility?
Some examples:
• Slider/carousel plugins
• Lightbox plugins
• Form generator plugins
31
32. Slider/carousel plugin example
32
Can I use or
stop the slider
using the
keyboard?
Can I attach
alternate text to
the images?
Buttons or links
or div?
And do they
label their
purpose?
33. Lightbox plugin example
33
Can I attach
alternate text to
the large images?
When lightbox
opens, focus
remains on
page below
34. Form plugin example
34
Do screen reader
users get to hear these
error messages?
Are these labels
linked to input
fields?
35. So plugins can affect accessibility
Plugin authors should sensibly follow the theme accessibility
guidelines, to avoid spoiling the accessibility of WordPress
websites.
35
My aim with this presentation is to try to encourage theme developers to think more about accessibility when they are building themes. I'm going to be talking briefly about the WordPress theme review process – and in some detail about the new accessibility section within the theme review process.
I want to demonstrate that taking onboard the points from the accessibility-ready section – even if you are not intending to submit your themes to the WordPress Repository – is not usually that difficult. And the upside is that you make websites built with your themes potentially more accessible – ie that more people can use them.
Although you may not have heard of the theme review process, I'm going to cover some aspects of web accessibility that it's useful to know even if you are not technical.
I work with organisations to help them improve the accessibility of their digital offerings. Do accessibility testing and guide designers and developers in solutions to the issues found.
WordPress developer – have built many accessible websites using WordPress.
I've delivered presentations to WordCamp London and WordCamp Sheffield – and this is me in Sheffield. The presentation is called So, How Do I Know if My WordPress Website is Accessible and focusses on easy accessibility tests that you can do on your own WordPress website.
If you've not seen me do that one – and I know that some of you have - the slides are still on Slideshare , and they've been viewed over 12,000 times now.
Short section on why I believe that accessibility matters.
Not all disabilities are ‘visible’. Not all people even consider that they have a disability.
Approx 20% of people have some form of disability or impairment
PWD represent a market worth £80bn per year in the UK – approx £320bn across EU.
If you don’t cater for these people then they’re not going to buy your (or your clients') services or products.
So if WordPress websites can’t be accessible then WordPress is automatically ruled out of the equation in some large and important territories.
How many people have built a WP theme for:
Their own site
For their clients
To be included in the WordPress theme repository
Who has never built a theme but has used one from the WordPress theme repository
All themes that are submitted to the WordPress repository go through a theme review.
Covers things like code quality, template files, hooks etc.
Themes that pass the review are allowed onto the repository
Q: Who has seen theme review guidelines?
There is a fairly new accessibility extension of the theme review .
Q: Who’s heard of it?
When you submit a theme to the repository you can now optionally assign the 'accessibility-ready' tag to your theme. Submitted themes that use this tag will go through an extra accessibility review stage that checks for conformance with the Theme Review Accessibility Guidelines.
A joint initiative from the Make WordPress Accessibility Team and the Themes Review team is working towards having every new theme submitted to the repository go through the accessibility ready check by the end of 2015.
Following that link on the page shows more details.
If a theme passes this accessibility review it can proceed onto the repository with the accessibility-ready tag. Themes that fail the accessibility review must be updated to meet the guidelines before they can be allowed on to the repository with the tag. Or the theme authors can remove the tag if they wish.
The guidelines for accessibility-ready are grouped into Required and Recommended. There's also a link to some accessibility resources.
You may ask about the term 'accessibility-ready' – why not just 'accessible' or 'accessibility'?
Well, a WordPress website's accessibility is not solely down to the theme. Plugins can adversely affect the accessibility of a site – as can the site admins and content authors for whom we've built the site.
The tag reflects this. It wouldn't be right if people claimed their website was fully accessible solely based on the use of a theme that featured good accessibility features.
Not all the themes in the first two searches carry the accessibility-ready tag
David is a member of MWAT and his Accessible Zen theme has been downloaded a few thousand times. It's mainly aimed at bloggers.
I'm going to briefly cover what's in each of these sections. I'm not going to be able to cover everything – you'll need to read the pages for that.
Be wary of having multiple levels of H1 etc – best to nest them sensibly.
Theme templates should use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup must NOT be used for presentational purposes. Heading elements for structure MAY be positioned off-screen as long as this is not at the expense of providing good, visual, structure.
Specifically, sub-sections defined by your theme MUST use heading elements. This includes wrapping your post title in a heading when used in an article context and wrapping widget titles in headings.
If a particular role appears more than once on a page, you should provide an ARIA label for that role:
<nav role="navigation" aria-label="<?php _e( 'Primary Navigation', 'textdomain' ); ?>">
<nav role="navigation" aria-label="<?php _e( 'Secondary Navigation', 'textdomain' ); ?>">
While it’s impossible to specify how many landmarks any given page should have, keep in mind that large numbers of landmarks can create a great deal of confusion for users who need to remember what information is in which landmark section. If you have more than 10, you may want to remove or consolidate some regions.
Links MUST avoid repetitive non-contextual text strings such as ‘read more…’ and should also make sense when taken out of context. Bare urls must NOT be used as links. Context-specific text MAY be positioned off-screen.
The core-defined ‘read more’ links fall under this guideline. You can use filters to replace these links. The post title should generally be used in addition to the normal directive text.
Can use hidden text to supply context
Non-standard elements can't natively get keyboard focus.
Screen readers need plain text to work with, or alternate text if images are used.
Dashicons, punctuation, maths symbols (eg < > + -) are likely to be ignored by screen readers
Theme authors MUST provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. Navigation by keyboard should also be intuitive and effective.
Focus – at minimum it should be the same as the hover style, but consider making it more than the browser default.
Dropdown menus must be operable by keyboard
accesskey – can hijack keystrokes from AT
Theme authors MUST ensure that all background/foreground color contrasts for plain content text are within the level AA contrast ratio (4.5:1) specified in the Web Content Accessibility Guidelines (WCAG) 2.0 for color luminosity.
Background/foreground color contrast also applies to change of state (:focus or :hover) if there is no additional indicator of :focus or :hover, such as a text decoration change.
The default settings will be the only color scheme checked. If a theme offers multiple color schemes, only the default scheme is required to pass these guidelines. Alternative themes should be clearly labeled if they do not meet accessibility guidelines.
Tools are available to help with this. See the Paciello Group contrast analyzer.
Themes MUST include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links MAY be positioned off screen initially but MUST be available to screen reader users and MUST be visible on focus for sighted keyboard navigators.
A minimally conforming skip link MUST:
Be the first focusable element perceived by a user via screen reader or keyboard navigation.
Be visible when keyboard focus moves to the link.
Move focus to the main content area of the page when activated.
There is an outstanding bug in WebKit-based browsers that prevents focus being moved to elements that aren’t natively focusable. You can either enqueue JS to patch this bug or assign tabindex=-1 to your main content region to handle this issue.
Comment forms MUST have appropriate field labels and all content within form tags MUST be explicitly associated to a form control. Post-submission responses (errors or confirmations) MUST be perceivable. If you are using the default WordPress comment or search forms, these pass the accessibility-ready criteria.
Forms that include a single input (such as a standard search form) may, optionally, position the input label offscreen. Themes that incorporate non-standard forms (e.g. a contact form) will be audited using the same criteria.
If you are replacing the default WordPress forms or form behavior (such as to handle responses with AJAX), you MUST:
Use form controls that have explicitly associated <label> elements.
Create feedback mechanisms (such as via AJAX) that expose responses to screen readers. Look at techniques with ARIA for further information.
Decorative images MUST be included using CSS.
Where theme authors add images to template markup or provide a method for end users to add images, theme authors MUST incorporate an appropriate alt attribute or the means for an end user to provide one. During the audit, the W3C alt text decision tree is used to determine whether images are using the alt attribute appropriately.
Example:
Featured Images: The alt attribute for featured images is defined in the media manager. In any case where a featured image is displayed, the alt attribute must be included with the image.
Icons and icon fonts: if the icon is representing text (e.g., there is no visible text), the icon must include fallback text for screen readers that indicates what the icon means. If the icon is supplementing text (e.g., it appears with text that indicates function or purpose), then the icon should not include fallback text, and should be hidden from screen readers using aria-hidden.
Media resources must NOT auto start or change without user action as a default configuration. This includes resources such as audio, video, or image/content sliders and carousels.
An important addition to this would be to provide a way to stop the slider/video etc.
Warning must be visible and accessible to screen readers
If a user zooms with text-only zoom enabled or has changed the base font-size in their browser, the site should support this without breaking the theme by creating overlapping or hidden text.
While the title attribute is occasionally of value, it is never of value if the attribute’s text is the same as the visible text. This is a common issue with post titles and permalinks. Remove extraneous title attributes.
Well, lets have a look.
Here are three popular types of plugin
I encourage people to refer to the theme review 'accessibility-ready' guidelines when they are building themes or plugin