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!
Here are my initial thoughts on how I believe RDFa will benefit web accessibility. If you are new to RDFa I recommend reading the Wikipedia entry on RDFa and the W3C RDFa primer as an introduction. Continue reading “RDFa – Implications for Accessibility”
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.
Continue reading “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.
Continue reading “Don’t Provide an Accessibility Statement”