A pragmatic approach to web standards and accessibility
I have created a Google co-op custom search engine with which you can search web accessibility guidelines. I have categorized each included page by country (for government guidelines) and I am adding more guidelines and categories. This means you can easily search e.g. the New Zealand guidelines for PDF recommendations.
If you work with accessibility guidelines you may find this useful. Suggestions are of course always welcome.
Many CMSs (content management systems) come with some kind of visual editor that allow editors to create and format content without knowing the markup involved. I evaluated some of these WYSISYG-editors back in March and found most of them lacking in features for semantic markup. One of the more commonly found problems is that they have a lot of features for visual formatting like font selection, font color, indentation etc. In most CMSs these are features you would like to avoid (ask your corporate communication department if they would like to have features that allow editors to go crazy with colors on the website…).
Som of you will argue that one should never use a WYSIWYG editor and instead deploy a wiki-style editing syntax like e.g. Markdown. This typically solves the problem, but in reality this type of syntax is very difficult for content editors to learn and becomes increasingly difficult if you want to do more advanced editing.
I was planning to start working on my own inline editor by forking TinyMCE and correcting what I thought was wrong with it when I found this comment from Jean-François:
[…] I’d like to present WYMeditor: WYMeditor is a web-based XHTML editor, not WYSIWYG, but WYSIWYM: the end-user can concentrate on rich content, while layout and design are handled via style-sheets.
This sounded almost too good to be true. WYSIWYM (What You See Is What You Mean) is of course how content for the web should be edited. WYMeditor is in an early stage of development, but after playing with it for a while it looks very promising. If it guarantees well formed XHTML it is an easy task to convert it to HTML 4.01 or any other representation you can think of.
Currently it works in Internet Explorer and Gecko-based browsers such as Firefox. You can try an online demo of WYMeditor here.
If content management systems were to use editors like WYMeditor web accessibility would get and instant boost. There are some issues that hopefully will be solved soon:
But, if I was developing a CMS I would definitely monitor the progress of WYMeditor.
Could WYMeditor make content editors aware of semantics in a way currently impossible in other inline editors? Will this type of inline editing merge with visual presentation à la XStandard?
EIZO has created a monitor that can simulate various types of vision deficiencies (PDF document). It is great to see hardware vendors making an effort to provide tools to improve accessibility, but this one makes me wonder. Do you really need to have hardware support for this? The advantage seems to be that you can test moving images more easily.
EIZO worked closely with the Color Universal Design Organization (CUDO) (also see english machine translation) in conducting experiments with colorblind test subjects to improve the ability to identify difficult to distinguish colors.
Fore those not fortunate to have access to an EIZO monitor, there are a number of software tools available to simulate how web pages and images look with various types of vision deficiencies:
What I haven’t seen is an application that isn’t confined to the browser, but works on top of your operating system. I guess this wouldn’t be very hard to do. Depending on the operating system it should be possible to have a filter applied to the entire screen. If you know of one, please post it in the comments below.
A couple of days ago I released RAAKT – The Ruby Accessibility Analysis Kit gem (I know, it really needs a better name). RAAKT is a gem that can be used independently of Rails and my plan was to make a Rails plugin that would add a custom assert method that did the check. It turns out that it only takes five lines of code so there is no need for a plugin. So let’s see how you can integrate accessibility checks into your current Rails application.
Continue reading “Automated Accessibility Tests with RAAKT in Ruby on Rails”
Content is often overlooked when working with a web site to increase accessibility. Even if your web site follows all W3C recommendations it will still be inaccessible if your content is difficult to comprehend. Let’s have a look at how you can measure text readability in english, spanish, swedish, danish and french to get a feel for the readability of your content.