13

Remove H1 Option from WordPress TinyMCE Editor

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.

03

Javascript for Added Accessibility

Imagine you’ve got a legacy WordPress site built using one of those drag/drop themes. Now complicate it by having a chunk of content created by a non-standard javascript-based slider plugin. Continue to imagine you have a very, very short window of time to bring it up to WCAG2.0 accessibility standards.1 Child themes aren’t a viable option because of the complexity and the tools that built this mess don’t even pretend to allow you to address most of the concerns. Enter our good friend javascript. I can now take our empty section elements and give them aria2 labels as Site Improve demands. One of the slider plugins was also attaching the same ID in two places. The weird one was on the HTML tag at the top of the document. That threw errors and was weird but it was also applied via javascript after the page finished loading so it was harder to get at. Awkward but apparently functional. 1 As interpreted by Site Improve . . . and yes it should have been there already but interpretation of WAVE vs Site Improve has some significant differences. 2 I’m pronouncing this like the opera solos but it’s actually stands for Accessible Rich Internet Applications

13

Working on Accessibility

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 […]