Minggu, 23 Januari 2011

RDFa – Implications for 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:


Tidak ada komentar:

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?

Tidak ada komentar:

September 2008 - Conference Round-Up: dConstruct 2008


September saw a lot of web conferences being held, some of which were attended by members of the Web Access Team.


Firstly we had dConstruct 2008, held in Brighton. The title of this year’s event was “Designing The Social Web”.


The day consisted of the following talks:



All in all it was a good day with all the talks being informative, interesting and inspiring me to think about the implications the social web has for accessibility in a wider sense.


I won’t be doing a full run down of the day here – that’s already been done elsewhere on other blogs. If you couldn’t make the day, Alastair Campbell from Nomensa has dConstruct 2008 notes which cover the day well on his personal blog. The podcasts of the talks are also starting to appear on the dConstruct website so make sure to check those out as they get released.


Talking of podcasts, a big thank you should go to Opera Software who sponsored the production of transcripts for the podcasts. These should also be available soon from the dConstruct website. It’s good to see a company sponsoring events such as this through providing something genuinely useful for a lot of people that couldn’t make the day rather than freebies for the attendees.



The Web Today


The web is an integral part of life for a lot of people. I, like many other people I know, feel out of the loop if I haven’t got access to the web for a few days. This situation can be exacerbated if you have a disability and have difficulty getting out of the house for example. For most of us, things such as online shopping and banking etc can be a more convenient way of doing something. If you haven’t got a car, online shopping can avoid you having to carry lots of bags on a bus for example. Similarly, online banking can be great if you don’t have time to physically get to the bank during the day. I can safely say through working with many people with disabilities over the last few years, that the web is usually more than a convenience to them. The web is often their lifeline to the outside world and more independent living and is invaluable.


The Social Web


The social web is no different. It holds a lot of potential to connect people with disabilities with each other in ways that were previously not available as easily or readily. Connecting online with people with similar types of disability to share thoughts, experiences and information presents a fantastic opportunity for self discovery. As with traditional online services, the benefits of the social web for people with disabilities are arguably greater than for those without disabilities.


Looking at this from the other side, social networks are totally reliant on people visiting and using their sites to be successful and profitable. Social networks that are almost always free to use, are often valued as businesses by the size of their user base that regularly use the site. Without the users, there is no social network and the site dies. This is of course true for any site or business, but is arguably more important for social networking sites.


Problems and Solutions


With this in mind, in my opinion social networking sites should really be taking accessibility and usability seriously. At present, some of the most popular social networking sites have some fundamental problems as highlighted in a recent eNation Report by AbilityNet. Social networking sites also highlight one of the other major challenges facing web accessibility at present, that of User Generated Content (UGC). The web is no longer being developed by professionals, it’s being developed by anyone who has access to a computer and enough knowledge to be able to create an online presence using tools no more difficult than a word processor.


As most users are not versed in accessibility, there are hopefully things that tool developers can do to help ensure that the authoring tools help users produce content that is accessible. The Authoring Tool Accessibility Guidelines (ATAG) are being developed to help ensure that authoring tools are usable by people with disabilities and that the content they produce is accessible and meets the Web Content Accessibility Guidelines (WCAG). As many social networking sites fall under the category of authoring tools, these guidelines could help to ensure these sites are available to as large a user group as possible, which at the end of the day is what they are all after.


Despite many of their accessibility problems, there is one shining light that many social networking sites currently offer, their Application Programming Interfaces (APIs). These APIs allow you to access the data and services of social networking sites from your own sites and applications. Essentially, you can build your own interfaces to the standard versions of sites. This concept inspired Christian Heilmann from Yahoo! to organize his own conference, called Scripting Enabled, where the concept of “accessibility mashups” was brought to the fore. I’ll be doing a post on Scripting Enabled and everything that has happened since the conference and hack day very soon so keep an eye out for that one.


While the ultimate goal is to have accessible and usable social networking sites for all, until sites like Facebook, MySpace, YouTube and Flickr etc start making accessibility and usability part of their design and development processes, accessibility mashups are a way to get around the current problems in an inventive way with great results.


Further Reading


Tidak ada komentar:

Call for Review: Authoring Tool Accessibility Guidelines 2.0 Working Draft


The Authoring Tool Accessibility Guidelines Working Group (AUWG) published a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) 2.0 yesterday.


The following is taken from the email sent to the Web Accessibility Initiative (WAI) Interest Group:


ATAG defines how authoring tools should help Web developers produce Web content that is accessible and conforms to the Web Content Accessibility Guidelines (WCAG). It also defines how to make authoring tools accessible so that people with disabilities can use the tools. An overview of ATAG is available for those who are new to the guidelines.


In this update, Part A, which addresses authoring tool user interface accessibility, is refocused. Part B is restructured to replace the concept of “Web Content Accessibility Benchmark” with a more straightforward relationship with WCAG 2.0. The Working Group welcomes feedback on these changes.


The Web Accessibility Initiative (WAI) encourages you to review the updated ATAG 2.0 documents and submit comments on any issues that you think could present a barrier to future adoption and implementation of ATAG 2.0. Please send comments by 6th January 2009 to the comment list, which is publicly archived.


Further Reading


Tidak ada komentar:

WCAG 2.0 Becomes A W3C Standard


The Web Accessibility Initiative (WAI) announced today that the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have become a full W3C Standard.


This is great news and something many in the accessibility world have been waiting for for a long time. Version one of the guidelines were released in 1999, which is a long time in anyone’s book, but in “web years” it’s a very long time!


Much has changed on the web since 1999 and WCAG 2.0 seeks to address many of the new accessibility challenges facing the web today. As a document, it’s much more flexible and testable than WCAG 1.0 and covers more than just W3C Technologies. Proprietary technologies such as PDFs and Flash etc are also covered.


The techniques document for WCAG 2.0 is also updateable which should help the guidelines move with technology, and not become out of date as quickly as WCAG 1.0 did.


As always, guidelines cannot guarantee accessibility unless they are understood and applied correctly, but they can go a long way towards helping developers and content editors get things right. Having a modern, stable version of the guidelines for today’s web is only a good thing.


Further Reading


Tidak ada komentar:

Contributing WAI-ARIA landmark roles to open source CMS themes


Sometime new technology suffers from a chicken and egg problem. For example, if no websites start using WAI-ARIA there will be few incentives for manufacturers of assistive technology or browsers to include support in their products.


At the European Accessibility Forum in Frankfurt (eminently organised by Namics) I met Steve Faulkner who has done a lot of research on WAI-ARIA (see Using WAI ARIA Landmark Roles). Although the specification isn’t finalized yet there are many advantages to WAI-ARIA and browser support is increasing.


With the help of Steve, I submitted a minor patch for the default WordPress theme that adds ARIA landmark roles. I believe that a simple thing like this would make the web a better place for a lot of people as well as making web development easier.


How to add WAI-ARIA landmark roles


For an overview of methods to work with landmark roles in existing HTML see Patterns for WAI-ARIA landmark roles in existing HTML.


How to check WAI-ARIA landmark roles


If you want to start working on implementing landmark roles in a theme, check out Juicy Studio’s Web Accessibility Toolbar Extension for Firefox or the YAML debug tool bookmarklet. These will aid you in checking that the markup you add is correct.


Adopt your favorite CMS


What other content management systems would you like to see support WAI-ARIA landmark roles? If more people could help to create patches adoption would increase rapidly.


Add your suggestions below (or better, create a patch and send to the developers).


Content management systems



Wiki tools



Forum applications



Layout generators



Hosted services



Web frameworks



  • Django
Tidak ada komentar:

Pitfalls of Web Accessibility Evaluation Tools


Summary: Automated web accessibility evaluation tools are hard to trust, understand and only provides feedback on a small amount of factors that influence accessibility. Also, a unified web evaluation methodology should be adopted to provide consistent results across tools.


Introduction


When you start working with web accessibility as a site owner you will typically be exposed to online accessibility evaluation tools recommended by your supplier. These tools typically let you enter a link to a web page after some automated checks are made you get a report of all the errors that were found.


While these tools may be a good way to convince your organization to increase funding for accessibility work you should be careful how you interpret their results. Your website may be good enough already and if you try to fix all reported errors you may be spending money in the wrong thing.


As an example of how difficult these tools may be to trust and understand I have selected some of the more popular ones from the Web Accessibility Initiative list of tools and performed some tests.


Letting accessibility evaluation tools test themselves


Here, each of the tools were pointed at their own starting page. When possible WCAG 1.0 triple A settings were selected.














































Self test result
ToolErrorsWarnings
Deque Worldspace66
WAVE00
Functional Accessibility Evaluator00
AChecker0115
Eval Access0124
Cynthia says10
TAW30

Very few errors as expected. After all, these tools are built by professionals and I would expect them to have checked their own service.


Letting them test each other


So, what do they say about each other? Only one way to find out.






























































































Cross test result (Application that performed the test in the header row)
ToolWorld-

space		WAVEFAEACheckerEval AccessCynthia saysTAWSum
Worldspace60341432353
WAVE430191192791
FAE400321111
AChecker52000144777
Eval Access1303601225
Cynthia says10011161311364
TAW8001011323

It is understandable that people find it hard to make use of web accessibility evaluation tools. How are you supposed to interpret these results? None of the tools are in agreement on any of the tested pages. Similar results would be returned for most pages you evaluate.


Observations



  • WAVE didn’t find any accessibility issues in any of the pages. Also, WAVE would display a fun error message if you try to make it check itself by URL (I had to copy and paste the source instead).

  • The output from many of the tools are really hard to interpret, especially if you are new in the field of web accessibility. The TAW tool, for example, displays tiny icons all over the page and you have to hover them to see what they mean.

  • Worldspace uses nested tables for layout (something that WAVE didn’t complain about).


What would be your advice for a site owner that wants to increase accessibility on his/her website? How can they check if their supplier did the right thing when creating the markup?


(Please leave a comment or send me an email if you find any errors).

Tidak ada komentar:
Langganan: Postingan (Atom)