In May 2013 StudioPress released the 2.0 beta version of the Genesis Framework. I was looking forward to this release because StudioPress promised to pay more attention to accessibility.
Genesis 2.0 now has HTML5 as doctype (and adds html5shiv for IE less then 9).
To the HTML roles and area’s for header, navigation, main, article and asides are added. This is a big improvement for accessibility.
Test environment: WordPress 3.5.1 (Dutch) with the Genesis 2.0-beta framework and the Genesis 2.0-beta sample child theme, including 3 footer widget area’s. With the widgets Search, Genesis Featured Page, Genesis – Featured Posts and Genesis – User profile. The plugins Genesis Beta Tester and Genesis Translations where added.
On genesisframework.com StudioPress installed the nighty build version. I checked this too at May 27 2013, because some issues in the beta version 1.0 where already addressed there.
So, what should be tested?
- W3C validation the theme should parse: no errors, most warning are allowed.
- W3C stylesheet validation
- WCAG2 validation, e.g. colour contrast, semantics of the HTML, scalable text, keyboard navigation, visual focus.
WCAG2 comes in 3 versions, A, AA and AAA. AAA is the most strict.
Not all sites need to be AAA, but a good WordPress theme should at least parse with the W3C standards.
The requirements for accessibility are described the previous Genesis review of version 1.9.
Tools used to test the accessibility:
- the online W3C validator
- W3C stylesheet validator
- W3C Semantic Data Extractor
- the FireFox Add-ons Accessibility Evaluator and Juicy Studio Accessibility Toolbar
Items to test:
- posts, with comments
- post formats
- Content – Sidebar
- Sidebar – Content
- Content – Sidebar – Sidebar
- Sidebar – Sidebar – Content
- Sidebar – Content – Sidebar
- Full Width Content
- Site title and / or image in the header
First: W3C validation
The goal is to parse, so no errors, warnings are allowed.
Some errors are generated by WordPress itself, I added that to the remarks.
General validation Errors
Meta names not known: Bad value wp_template for attribute name on element meta: Keyword wp_template is not registered.
Unchecking “Display Theme Information in your document source” solves this meta problems.
Attribute rel errors Bad value category for attribute rel on element a: The string category is not a registered keyword or absolute URL. rel="category">name category
This is not a Genesis but a WordPress issue (in wp-includes/category-template.php).
The template post-formats generates a lot of validation errors (on May 27). Not sure if this is work in progress. I will look into this when a later beta version of framework is released.
Attribute error Attribute results not allowed on element input at this point. input type="search" name="s" placeholder="Zoek op deze website…"
It’s a neat option, it just doesn’t validate (yet?).
Social Media widget
On genesisframework.com a widget with social media buttons was added. This widget generates the error:
Document uses the Unicode Private Use Area(s), which should not be used in publicly exchanged documents. (Charmod C073)
- Unknown pseudo-element or pseudo-class ::-moz-selection
- Unknown pseudo-element or pseudo-class ::selection [selection]
I think that’s an error we can live with. It doesn’t bother anyone, except the validator. And it’s easily removed from the style.css in your child theme, if you want to validate the CSS completely.
Some templates and widgets use inline styles like the Post Formats template. Better add an extra stylesheet in the header when needed.
For an accessible theme the following colour contrasts need to be changed:
- The link in the menu’s is only indicated as active by colour (gray turns white).
- Text in #999 with a #fff background has an insufficient luminosity contrast ratio for WCAG2 AA and AAA
- Text in #666 with a #fff background has an insufficient luminosity contrast ratio for WCAG2 AAA
- Text in #fff with a #f15123 background has an insufficient luminosity contrast ratio for WCAG2 AAA
- Text in #999 with a #333 background has an insufficient luminosity contrast ratio for WCAG2 AA and AAA
- A link inside the content is red with a bottom-border #ddd. For meeting WCAG2 requirements the border-colour should be at least #555
This all can easily be adjusted in a custom child theme.
Juicy Studio colour contrast report in PDF, opens in a new window
Social media widget
I’m not sure of this will be a part for the framework, but just in case it will be: the images are generated with the fontello font generator using Public Unicode Character Map.
Inside the a elements there is no content provided about the icon used.
A solution for this are provided at A List Apart.
Genesis and semantics, never the twain shall meet. For me this is the biggest problem with the Genesis framework, because it needs rewriting templates and adding fixes into the functions.php.
Some issues with the headings
In a post the “about author” has an H1 heading (maybe a H2 will be better). A page should only have one H1.
The comments and :speak your mind” have an H3, this is a problem when the post itself has no H2
The site title on the homepage is put inside an H1 and on other pages inside <a> element. It’s also a link to the homepage, OK so far. But it would be better if the link to home was removed on the homepage. A link to the page itself doesn’t make sense.
The notorious H4
Widget titles have as heading an H4. Running the site through the W3C Semantic data extraction shows how a site is organized based on headings. For example, the H4′s of the sidebar reside below the last post for an archive. Not only for accessibility, but also for SEO reasons this seems not logical.
In the widget Featured Post and Featured Page, the post/page title is an H2 heading, setting the semantics in: H4 for the widget title and after that H2′s for the post titles.
The archive template skip the H2 and H3 and list the sitemap with H4 headings. An H2 would be a better solution here.
Ok, it’s hard to change the widget heading, for so many themes and plugins for this framework are using this.
Maybe it’s an option to have the heading structure of widgets added to the theme settings (or the function genesis_register_sidebar( $args ). Default an H4, but optional an H3 or H2?
Don’t skip an heading level, the best way to do this is to have one H1 (the page title) and an H2 for the widgets. Or give the asides like footer or sidebar, a (hidden) H2 and the widgets an H3.
That way the content manager can’t mess up the semantics for the entire page.
Other accessibility issues
The use of a title attribute in a link or image. This is perfectly valid HTML, but some screen readers ommit this title, others can read it. If the content of the title and the link text is the same, the two will be read out after each other (like Genesis Sample Theme).
Better remove all title attributtes. And if you want to use them: don’t put double or essential content in them.
Steve Faulkner wrote an excellent article about this: HTML5 Accessibility Chops: title attribute use and abuse.
Conclusion and recommendations
- I love the fact that the framework usesHTML5
- The semantics of the heading still need improvement although it’s better than the previous versions of the framework, now every page has a proper H1
- The title attributes on images and links should be removed
- The colour contract is not according to WCAG2 standards, but this can easily be changed in a child theme
- Some widgets and templates use inline style, better add an extra stylesheet in the header when needed.
- Give images that are not essential for the content, like thumbnails an empty alt (alt=”")
I wrote this review as way to organise the work I have to do, to build accessible child themes for this framework. If you disagree with my findings or find other accessibility issues with this framework, please let me know.
A big thanks to Bram Duvigneau for testing the code with a screen reader, discussing and offering solutions.