I am very grateful for all the discussions and feedback I have received on my accessibility articles over the years but it is now time for this website to be archived. It has not been updated for several years but when I tried to remove the website a couple of weeks ago I got a lot of emails from people who were looking for content so I guess it still serves a purpose. Therefor I will keep the website online, but comments will be disabled. Thank you for trying to make the web abetter place for everyone!
Archive for the 'General' Category
A bit of background on RDFa
RDFa is a set of extensions to HTML and XHTML from W3C. With RDFa it is possible to use custom vocabularies to include machine readable data in web documents. In current web documents based on HTML or XHTML there are very limited ways of expressing information for machines. There are:
- HTML elements that express document structure (e.g. headings, lists, tables), and rethoric (em, strong),
- (broadly defined) HTML elements that express various technical terms (code, kbd, samp), and,
- the content itself.
As more business domains are moving online the need to exchange data in a more structured fashion will increase. Instead of publishing data twice, once in a web document for humans and once in a separate file for machines, RDFa makes it possible to include machine readable data in web documents. (In a way, this has been possible since the modularization of XHTML, but in practice, few developers seem to have used the extension mechanisms of XHTML).
An RDFa example
Consider the following XHTML markup:
<p class="contactinfo"> My name is Jo Smith. I'm a distinguished web engineer at <a href="http://example.org">Example.org</a>. You can contact me <a href="mailto:firstname.lastname@example.org">via email</a>. </p>
Most humans will be able to understand the information but for machines this markup is too vague to parse without ambiguity. By providing more information about the content we can reduce this ambigity. First we provide information about our vocabulary in the HTML element:
Then we can use the terms of that vocabulary to provide more information for machines:
<p class="contactinfo" about="http://example.org/staff/jo"> My name is <span property="contact:fn">Jo Smith</span>. I'm a <span property="contact:title"> distinguished web engineer </span> at <a rel="contact:org" href="http://example.org"> Example.org </a>. You can contact me <a rel="contact:email" href="mailto:email@example.com"> via email </a>. </p>
One of the major benefits is that there is a standard for the vocuabulary specification and it is machine readable. You can open the URI for the vcard vocabulary used above in your browser (you may have to “view source” to see it) and see more information about the terms of the vocabulary. Another big advantage is that you can create a vocabulary specification for your business domain yourself and publish on the web. You do not have to put it through some central authority.
We have now modified the markup in our document to make it useful for both humans and machines. The document still looks the same for sighted users that look at the information in their web browser. Apart from the added benefit for search engines and desktop applications (e.g. importing this information into your adressbook now becomes easier) I believe it will have interesting implications for assistive tools as well.
What if assistive software could use RDFa information?
Since the vocabuary is created in a machine readable format it should be possible to let assistive software such as screen readers load the vocabulary specification and provide more information for the user. If you look at the vocabulary specification for vcards used above each term has a label text. For the title the specification looks like this:
One of the simplest ways of using this information is of course to read it to the listener during the linearization of the page. Since a term can have a description too even more information could be provided to the user.
In practice, the sequence of events for a screen reader working on top of a web browser could look like this:
- Browser opens the web page.
- Screen reader parses the HTML and extracts references to all external vocabularies.
- External vocabularies are fetched and parsed for labels and descriptions.
- The screen reader announce that extended information exists and starts rendering the page.
So, by using RDFa to reduce ambiguity for machines it is likely that humans too can benefit from the added information. It will be very interesting to see what makers of assistive tools can come up with. What other use cases for RDFa with regards to accessibility can you see?
For more information on RDFa see:
Web accessibility is, in my experience, often considered late in the development process. Typically, accessibility evaluation is conducted by outside experts after the application is delivered and content is produced. This leads to issues being reported to developers late in the project, at a time when changes cost more.
In order to make accessibility development efforts more efficient I believe that accessibility has to be integrated into all stages of a project with as much automation as possible. Here are some ideas on how this can be done for the developer role.
Read more about Bringing Accessibility into the Development Process
Verva, the Swedish Administrative Development Agency has released an updated version of the guidelines for Swedish public sector web sites. The document is used by public organizations when procuring new web sites as well as by developers as an aid in the development process.
No english translation is available yet, but I know there will be a summary in english in the beginning of 2007. In the meantime, here is an overview of the guidelines:
- Efficient service – use technology as a tool to optimize your organization processes. Use standards for information exchange.
- The development process – integrate usability in the development process and don’t detail requirements upfront.
- Web site standards – use technical standards as well as standards for structure, navigation and design. Code for a markup standard rather than targeting specific browsers.
- Web site content and services – minimum requirements for web site content. Provide basic information in sign language and minority languages.
- Keeping the web site alive and up to date – write in a clear and simple lanugage (for a summary see my previous article “Working with content…”), monitor traffic statistics and learn user behaviour.
- Considerations for mobile terminals – ensure the web site works resonably in a mobile terminal. Provide a stylesheet for handheld terminals. Use the W3C Mobile web best practices for more information.
- Content management systems – guidelines for choosing a CMS: should handle web standards, should not force the editor to use a specific web browser, technology independent URLs, should have integrated support for accessibility checks.
- Assistive technologies for web browsing – introduction to assistive devices and ways users may access the web site.
If you are interested in knowing more about a particular chapter, post a comment below and I will try to expand the translation in that particular area. I have contributed as a co-author to some of the guidelines in this version as well as the previous.
When I surf the web I see more and more sites providing an accessibility statement. Googling for “accessibility statement” returns over twelve million pages. What do these statements contain? Why would you want one? Who reads them? This article will try to make two points: 1. accessibility statements are often pointless and 2. you are better off with a “site help” if you think your target audience need it.
Read more about Don’t Provide an Accessibility Statement