Content – Standards Schmandards http://www.standards-schmandards.com A pragmatic approach to web standards and accessibility Thu, 12 Jan 2017 21:17:39 +0000 en-US hourly 1 https://wordpress.org/?v=5.8.4 RDFa – Implications for Accessibility http://www.standards-schmandards.com/2007/rdfa-and-accessibility/ http://www.standards-schmandards.com/2007/rdfa-and-accessibility/#comments Tue, 04 Sep 2007 21:26:05 +0000 http://www.standards-schmandards.com/2007/rdfa-and-accessibility/ 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.

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:jo@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:

<html xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#">

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:jo@example.org">
		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:

<rdfs:label>Position Title</rdfs:label>

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:

  1. Browser opens the web page.
  2. Screen reader parses the HTML and extracts references to all external vocabularies.
  3. External vocabularies are fetched and parsed for labels and descriptions.
  4. 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?

References

For more information on RDFa see:

]]> http://www.standards-schmandards.com/2007/rdfa-and-accessibility/feed/ 16 Mental Workload for Paged and Scrolled Documents http://www.standards-schmandards.com/2007/paged-or-scrolled/ http://www.standards-schmandards.com/2007/paged-or-scrolled/#comments Sun, 24 Jun 2007 21:12:18 +0000 http://www.standards-schmandards.com/2007/paged-or-scrolled/ Continue reading "Mental Workload for Paged and Scrolled Documents"

]]> In a recent doctoral thesis from the department of psychology at Gothenburg University, Sweden, Erik Wästlund provides some interesting findings on mental workload for consumption of information. Two of the principal findings are:

  1. Consumption of information is more efficient when information is presented on paper compared to presenting the information on a computer screen.
  2. Consumption of information generates less mental workload when the page layout is adapted to fit the screen.

The first point may not come as a surprise. Steve Krug has argued that users tend to scan web pages rather than read them and Erik’s study cites previous research that says users tend to have difficulties reading longer passages of text on a screen.

A fundamental characteristic of reading information on a computer screen is that it “involves both the process of reading the presented text and handling the computer. The reader’s processing capacity is being utilized not only for decoding but also for page navigation.”. When we read e.g. a book the mental workload is low because we know from experience where to focus after turning a page.

Adapting content to the screen

The second point has some interesting implications for people working with the web. Currently, web pages with a lot of text tend to come in two flavors:

  1. All text on a single web page and the standard browser scrollbar to move forward in the page. (Example: A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft).
  2. Paged text and one or more navigation buttons to move to the next page. (Example: Mark Pilgrim’s Dive Into Accessibility, Day 6: Choosing a DOCTYPE).

Paged text on the web today is rarely adapted to the browser window size.

In Erik’s study the test subjects were given reading assignments. One group read the document in a scrolled format (number 1 above) and the other group read the document in a paged format where the page format was adapted to the computer screen.

The result showed that mental workload was lower when you read information in a paged way adapted to the screen. This is interesting as the current technology for constructung web pages (HTML and CSS) do not provide an easy way to page text adapted to the user’s screen. I am guessing that it may be possible by using javascript to measure the window size and create keys to move forward by a viewport page at the click of a button.

On the other hand, most browsers provide this functionality for scrolled pages in the Page-up and Page-down keys. In the usability tests I have participted in during the past years I can not recall a single user using the Page-up/down keys.

So, does this mean that scrolled text is better if user’s learn to navigate with the Page-up/down keys? Or should content authors paginate long documents? Will these methods have other accessibility implications?

]]> http://www.standards-schmandards.com/2007/paged-or-scrolled/feed/ 21 Visually Editing Semantics – What You See Is What You Mean http://www.standards-schmandards.com/2006/wysiwym/ http://www.standards-schmandards.com/2006/wysiwym/#comments Tue, 05 Dec 2006 20:36:08 +0000 http://www.standards-schmandards.com/2006/wysiwym/ 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.

WYMeditor to the rescue

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.

WYMEditor interface showing the markup structure of a text.

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:

  • icons for strong emphasis and emphasis look like bold and italics,
  • heading levels can be mixed in a non-logical way (like inserting h5 after h1)
  • support for som elements like acronym, abbreviation and definition lists, are missing

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?

]]> http://www.standards-schmandards.com/2006/wysiwym/feed/ 33 Don’t Provide an Accessibility Statement http://www.standards-schmandards.com/2006/just-say-no/ Sun, 22 Oct 2006 21:25:32 +0000 http://www.standards-schmandards.com/2006/just-say-no/ 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.

A recent study by Digital Media Access Group, Evaluating the Usability of Online Accessibility Information, came to the conclusion that accessibility statements often are difficult to comprehend for users. In fact, naming them “Accessibility statement” meant that many users did not look at them at all. This, of course, isn’t strange. The meaning of the word “accessibility” isn’t clear to everyone.

The Current State of Statements

Looking through some of the accessiblity statements you find on the web I can’t help noticing the amount of technical jargon. Many of them contain information about the accessibility testing procedures used when building the website. Why would a user want to know about that? My guess is that companies are trying to promote the image of themselves as being good net citizens. Looking through some of the pages returned from the Google search reveals some similarities. Sample fragments:

  • “All pages on this site are Bobby AAA approved.”
  • “WCAG AAA approved.”
  • “Valid HTML 4.01 Strict”

For the average user this means absolutely nothing. A page filled with technical jargon is likely to be skipped by many users. These types of accesibility statements are pointless.

Providing a site help instead

The report Evaluating the Usability of Online Accessibility Information shows that a “site help” is much more efficient compared to an “accessibility statement” provided you don’t fill it with technical crap. This, of course, is nothing new.

As with all other information you should start by defining your target audience. Depending on your audience and the functionality of your site you may come to the conclusion that there is no need for even a site help. If you know your target audience you can establish a baseline of technical knowledge. This baseline will aid you in making decisions on what should go into the site help.

This blog, for example, assumes that the reader knows that underlined text can be clicked and how to use the search field, hence the lack of an accessibility statement.

So, get rid of your “Accessibility statement” today and provide some useful information instead. Different opinion? Post your comments below.

]]> Methods for measuring text readability http://www.standards-schmandards.com/2005/measuring-text-readability/ http://www.standards-schmandards.com/2005/measuring-text-readability/#comments Fri, 09 Sep 2005 15:17:16 +0000 http://localhost:8888/?p=24 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.

]]> 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.

In this article we will have a look at how you can test your content to see give a brief overview of formulas for measuring readability as well as an online tool to measure readability for your texts.

Content is commonly 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. As previously mentioned here and elsewhere you can do a lot to increase accessibility by working with your content.

The technical aspects of accessibility is often more easy than the content aspects. If you are reading this you probably already know how to create an accessible web site by using the W3C recommendations. You also know how to use the W3C validator to test your templates before you put them onto your live site. Content, on the other hand, varies over time and is often created by a large number of people, each with their own personal style of writing. It is also more difficult to test using an automated tool.

Measuring readability of a text

There are a number of methods to measure the readability of a text. Most of them are based on multiple correlation analysis where researchers have selected a number of text properties (such as words per sentence, average number of syllables per word etc) and then asked test subjects to grade readability of various texts on a scale. By looking at the text properties of these texts it is possible to correlate how much “words per sentence” influence readability.

Some important facts about readability measurement methods:

  1. Readability index formulas only work for a specific language.
  2. Readability does not equal understandability.
  3. A readability index score is not an exact science. For example, it does not consider disposition (paragraphs) or actual content (are the words from a specific domain?).

Having said that we can move on to testing our content.

The readability index calculator

I have created a simple tool where you can calculate a readability index score for a text of your choice. To see a comparison, please try it with a legal document such as an EULA (End user license agreement) which typically is difficult to read. The calculator uses the following formulas:

After you are done testing your own texts, come back here and read more on what you can do to increase readability of your content.

What you can do to improve readability

If you have a large web site with many editors you should make sure all of them have a basic understanding on how to write for the web. Implementing a publishing policy and making sure it is used will ensure that your visitors get a consistent style when visiting your web site. The policy could include the following guidelines:

  1. Explain abbreviations and acronyms the first time they are used (do not rely on markup alone).
  2. Provide a subset of your content in basic english or the corresponding basic version of your language. Sweden has an organization that provides training in easy-to-read swedish. Your country/language may have similar institutions.
  3. Try to keep sentences short.
  4. Avoid symbolic language (metaphors).
  5. Avoid complicated words. Make sure you are writing from your user’s point of view. Use their terminology instead of your own.
  6. Write for the web (see Seven Krug’s book Don’t Make Me Think). Writing for the web differs from writing e.g. a scientific report. Fore more information see the references section below.

References and more information

]]> http://www.standards-schmandards.com/2005/measuring-text-readability/feed/ 18