In terms of basic accessibility guidelines each page should have only one H1 element. In WordPress that’s usually built into the template and is usually the title of the post or page. I was thinking about that last night and wondered if we should just remove it as an option from the TinyMCE editor in WordPress. Removing options goes against my typical stance but I couldn’t think of any scenarios that demanded an H1 element but plenty of scenarios where offering it seemed like it’d create confusion. A brief perusal of the WordPress Codex’s TinyMCE section led to the code above. I put it in our generic network-activated plugin for Rampages. Next steps could include integrating a filter in kses to remove/replace H1 elements with H2 elements but that’ll wait for now as it seems a chunk more aggressive.
Bean with Tools on the Ocean of Storms flickr photo by NASA on The Commons shared with no copyright restriction (Flickr Commons) We’re taking a much deeper dive into accessibility lately. It is a fruitful and good thing to do but also one of those deceptively deep topics with lots of complications. As a result I’m learning a good bit so I better write it down before it’s all forgotten. Two Handy Tools Thanks to both Matt and Jeff, I ended up using a few different tools.1 Google’s Vox Plugin helps you get a better idea what the experience was going to be like for someone with issues seeing the website. Using this will enable you to understand exactly how some of your decisions play out. I found it very handy. As a minor warning, there appears to be no way to turn it off/on short of disabling the extension. Despite that, I really think it’s a good idea to spend some time using this tool. It really helps. The other useful tool so far has been the Siteimprove Chrome extension. It’s pretty handy to see what warnings/failures are in play in each page. It’s led me to realize that there are so many problems. Bits of Useful Code One of VCU’s requirements is a text only view for the […]