On Januari 7, 2013 StudioPress released an update for the Genesis Framework. I love this framework. It’s flexible, well organized , with a lot of extra hooks and filters and with an excellent support and a large community.
It takes work to build an accessible theme using this framework, and it would be perfect if Genesis was WCAG 2.0 compliant out of the box. So hereby my review and recommendations on the accessibility of the Genesis Framework 1.9.
In this review I only address the errors in the Genesis output, knowing that a lot of options can be added to make it perfect. Some accessibility issues are WordPress core related. These are discussed in the group Make WordPress Accessible.
My first impression of the new theme was a good one. I love the new Lato font, and the way the font sizes are defined scaleable with rem units. Some issues are still remaining, like missing H1′s on archive pages and the semantics of the (widgets) headings.
Used setting: WordPress 3.5.1 with the Genesis 1.9.1 framework and the default sample child theme, including 3 footer widget area’s. With the widgets Search, Genesis Featured Page, Genesis – Featured Posts and Genesis – User profile. No extra plugins where added.
- posts, with comments
With the layouts:
- Content – Sidebar
- Sidebar – Content
- Content – Sidebar – Sidebar
- Sidebar – Sidebar – Content
- Sidebar – Content – Sidebar
- Full Width Content
- Site title and / or image in the header
W3C HTML validation
Used validator validator.w3.org/
Result HTML validation
- The output of the Genesis Widget User Profile is missing a </p> at the end of the widget content, if “Show Author Archive Link?” is checked. Maybe using a span instead of a div for the archive link container doesn’t confuse the function wpautop in user-profile-widget.php line 96.
- With comments: aria-required=”true” doesn’t validate for XHTML 1.0 Transitional, it only does for HTML5.
W3C stylesheet validation
Used validator: jigsaw.w3.org/css-validator/
Result stylesheet validation
- 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.
WCAG 2.0 colour validation
WCAG 2.0 A colour requirement
Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Colour results for WCAG 2.0 A
- The link in the menu’s is only indicated as active by the red colour.
- In Archive pages the link (and the title) to a post is not visually a link.
WAGC 2.0 AA colour requirements
- The visual presentation of text and images of text has a contrast ratio of at least 4.5:1
- Large-scale text and images of large-scale text have a contrast ratio of at least 3:1
Colour results for WCAG 2.0 AA
- The grey colour #999999, for blockquotes and for the search widget, fails, contrast ratio is 2.85:1
- The red colour #ff2a00, for links fails for normal text, but passes for large text, contrast ratio is 3.76:1
WAGC AAA colour requirements
- The visual presentation of text and images of text has a contrast ratio of at least 7:1
- Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1
Colour results for WCAG 2.0 AAA
- Site description: #636363 validates only for large text only, the contrast ratio is 6.01:1
- Input text with the Searchbox “Search this website …” #999999 fails, contrast ratio is 2.85:1
- The red colour #ff2a00, used for links fails, contrast ratio is 3.76:1
- The grey colour #636363 used in e.g. post-meta and post-info classes passes for large text only, contrast ratio is 6.01:1
WCAG 2.o about semantics
Or in short: the elements are used according to their meaning, not because of the way they appear visually.
The HTML order of the content and sidebars and footer is excellent. Removing the stylesheet leavs a perfectly logical order of content for all layouts.
This is the biggest accessibility issue with the Genesis framework, the titles/headings are not on a semantically good order:
- The Archive and Search pages are missing an H1
- The 404 page and archive template skip the h2 and h3 and list the sitemap with H4 headings
- All widgets have an h4 heading
- The comments and :speak your mind” have an H3, this is a problem when the post itself has no H2
- In the widget Features Post, the post title is an H2 heading, setting the semantics in: H4 for the widget title and after that H2′s for the post titles.
The site title on the homepage is put inside an H1 and on other pages inside a <p>. It’s also a link to the homepage. That’s good.
It would be better if the link to home was removed on the homepage. A link to the page itself doesn’t make sense.
If only a header image is used, the site title and description are hidden by style and readable by screen readers. That’s good.
Links and images
Title attribute on links and images: please remove them all, some assistive technology and browsers don’t handle titles very well or differently. I think it would be better to add the title to the “read more” link itself. I know this is a big point of discussion, it messes up the design. But every link should stand on it’s own. A ton of “read more” links to different locations is confusing to navigate with assistive technology. Removing the “read more” links all together and emphasizing the post title as link could be an alternative.
WCAG 2 about the alt attribute on images (alt text): When an image contains words that are important to understanding the content, the alt text should include those words.
To my opinion the alt text is not necessary with the thumbnails in archive pages. Especially because most users don’t bother to fill out the alt text and then the alt text is filled with the image name, resulting in an alt text like “IMG_12345″.
- Add an H1 to each page/template
- Change the heading of the widgets into an H2, and set the title inside the widget Features Post to a H3.
- Fix the output of the Genesis Widget User Profile
- Change the #ff2a00 into #aa0000
- Change the #636363 into #595959
- Change the #999999 into #595959
- Underline active links in the menu’s, or find another visuel way of distinguishing an active link
- Underline linked titles in the archives, or find another visuel way of distinguishing a link
- Give more contrast to the borders on the input fields, change the border colour from #ddd into a bit darker colour (not a requirement, just a tip to make the site more usable for people who can’t see low contrast).
- Remove title attributes from images and links
- Remove the alt text from thumbnails
- Remove the link to the homepage for the title on the homepage
And, not accessibility related
If you add a title to the search widget in the header, the space between the title and the widget is a quite large. #header .search-form has a margin-top of 56px/3.5 rem. And the title is placed above that.
Conclusion WCAG 2 validation
The stylesheet is much and much better than the 1.8 version. The fonts in the relative rem units is a big improvement. The colour scheme is improved, not perfect, but much better. The semantics of the headings is still a major problem. The semantics of the header, the content, sidebars and footer is excellent.
For all the new options in WordPress and the plugins an HTML5 Doctype is a far better choice. This is on the road map for Genesis 2.0 thankfully. I hope the semantics of the headings will also be a part of the new version.
I wrote this review as way to organise the work I have to do, to build an accessible theme for this framework. If you disagree with my findings or find other accessibility issues with this framework, please let me know.