Themes Plugins and Accessibility - WordCamp London March 2015
ā¢
2 likesā¢2,833 views
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.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
Similar to Themes Plugins and Accessibility - WordCamp London March 2015
Similar to Themes Plugins and Accessibility - WordCamp London March 2015 (20)
More from Graham Armfield
More from Graham Armfield (20)
Recently uploaded
Recently uploaded (20)
Themes Plugins and Accessibility - WordCamp London March 2015
- 1. Coolfields Consulting www.coolfields.co.uk @coolfields Themes, graham.armfield@coolfields.co.uk @coolfields Plugins & Accessibility
- 2. What Iām Going to Cover ā¢ Why web accessibility matters ā¢ WP theme review process and the 'accessibility-ready' tag ā¢ Plugins and accessibility 2
- 3. A bit about me 3 Iām aā¦ ā¢ Web Accessibility Consultant ā¢ WordPress Developer Photo by Mike Pead @coolfields
- 4. Coolfields Consulting www.coolfields.co.uk @coolfields Why is Accessibility Important? What's all the fuss about?
- 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
- 7. Coolfields Consulting www.coolfields.co.uk @coolfields Theme reviews and accessibility
- 8. Coolfields Consulting www.coolfields.co.uk @coolfields Themes ā¢ for us ā¢ for our clients ā¢ for WordPress
- 11. The 'accessibility-ready' tag 11 https://make.wordpress.org/themes/handbook/review/accessibility/ Guide for reviewers: http://make.wordpress.org/accessibility/theme-accessibility-guide-for-reviewers/
- 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
- 17. ARIA Landmarks <header role="banner"> 17 <nav role="navigation"> <footer role="contentinfo"> <main role="main"> <aside role= "complementary"> role="search"
- 18. Link text ā¢ must supply context ā¢ no bare urls 18
- 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
- 21. Colour contrast ā¢ background/foreground ā¢ WCAG 2.0 ratio - algorithm ā¢ theme colour schemes (http://www.paciellogroup.com/resources/contrastanalyser/) 21
- 22. Skip links ā¢ direct to content ā¢ direct to navigation ā¢ first focusable element(s) on a page 22
- 23. Forms ā¢ explicitly linked labels ā¢ error messages reachable by screen readers 23
- 24. Images ā¢ decorative via CSS ā¢ alt attributes 24
- 25. Media ā¢ includes: audio, video, sliders, carousels ā¢ no auto start without user action 25
- 26. Popups Without Warning ā¢ warn users first ā¢ warning should be visible and accessible to screen readers 26
- 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
- 29. Coolfields Consulting www.coolfields.co.uk @coolfields Plugins and accessibility
- 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
- 36. Rememberā¦ Every accessibility step you take makes the web easier for someone. Please take your next step soon. 36
Editor's Notes
- 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