General – 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 This website is now an archive http://www.standards-schmandards.com/2015/this-website-is-now-an-archive/ Sun, 19 Apr 2015 07:29:47 +0000 http://www.standards-schmandards.com/?p=193 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!

]]> 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 Bringing Accessibility into the Development Process http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/ http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/#comments Fri, 30 Mar 2007 14:49:18 +0000 http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/ 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.

Project roles and process

Consider the typical staffing of a web development project and how the respective roles relate to accessibility:

  • Designers create the user interface design. The design needs to be checked for visual aspects such as contrast issues, choice of color, font readability etc. The designer deliverables are often due early in the project.
  • Developers create the markup and application logic for the application. The markup has needs to be checked for technical accessibility issues such as correct markup of tables, forms, document structure etc. The developer devliverables appear throughout the project.
  • Content producers (copywriters) create text. The text has to be checked for readability issues and other language aspects. Content is often delivered towards the end of the project.

Accessibility experts typically appear at the end of the project to test the application. This is natural as it isn’t until the end that the majority of design, markup and content is available for testing.

Implications

The problem with this approach is that the time between feedback from the accessibility evaluation and the work done is too long. Proponents of agile development methods identified this a long time ago and it is typically illustrated with the cost of change curve:

Rapid feedback with an automated tool gives lower cost of change than slow feedback.

In essence, rapid feedback is easier to act upon and incurs a lower cost of change. Getting the feedback later means that you as a developer may have implemented more functionality in an inaccessible way. There may also be more dependencies developed that affect the parts that you need to change based on the late feedback.

So, if possible we would like to have a tool that provides rapid feedback throughout the development process to all project roles. By “rapid” I am referring to near instantaneous feedback to minimize context switching for the developer.

Challenges with automated accessibility evaluation tools

The challenge with accessibility testing is that many things are difficult to automate. Content, for example, is hard to do an automated assessment of. You may calculate all the readability scores you want but only real user testing will give you enough information to conclude if your content is understandable.

Contrast and color is also difficult. Developers may have used combinations of javascript, css and markup to create the final look. To have a machine understand the actual contrast ratio for a specific text may be nearly impossible if you don’t roll your own browser implementation.

Other challenges include integrating a tool into your project’s continuous integration framework. This rules out many of the web based tools available.

A proposed solution

If you haven’t heard of Raakt (The Ruby Accessibility Analysis Kit) before, there is a quick introduction on the Raakt wiki. Raakt focuses on the developer role in a project and helps developers make sure that the created markup passes a set of basic accessibility tests. It integrates with many test frameworks to become part of the automated test cycle.

The ambition is to make basic technical accessibility testing a natural part of a development project’s test suite. This will hopefully improve markup quality and minimize the number of accessibility issues found in subsequent tests. It also helps developers with little or no accessibility knowledge to get on track faster.

I would be very interested in receiving your feedback on what you think about this approach. How can accessibility become a more natural part of a development project? In your experience, would a project benefit from rapid accessibility feedback? Have you tried Raakt and did you find it useful?

References

]]> http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/feed/ 29 New Version of Guidelines for Swedish Public Sector Web Sites http://www.standards-schmandards.com/2006/swe-guidelines/ http://www.standards-schmandards.com/2006/swe-guidelines/#comments Tue, 14 Nov 2006 20:50:41 +0000 http://www.standards-schmandards.com/2006/swe-guidelines/ 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:

  1. Efficient service – use technology as a tool to optimize your organization processes. Use standards for information exchange.
  2. The development process – integrate usability in the development process and don’t detail requirements upfront.
  3. 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.
  4. Web site content and services – minimum requirements for web site content. Provide basic information in sign language and minority languages.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

]]> http://www.standards-schmandards.com/2006/swe-guidelines/feed/ 18 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.

]]> Accessible Art for the Visually Impaired http://www.standards-schmandards.com/2006/accessible-art/ http://www.standards-schmandards.com/2006/accessible-art/#comments Fri, 20 Oct 2006 19:14:24 +0000 http://www.standards-schmandards.com/2006/accessible-art/ Continue reading "Accessible Art for the Visually Impaired"

]]> A visitor is using her hands to explore a tactile object representing Henri Matisse's painting Apollo.This post is not about web accessibility, but I hope you will find it interesting nonetheless. The Stockholm Museum of Modern Art (Moderna Museet) created an interesting project to make some of its exhibits accessible for visually impaired visitors.

By creating tactile objects visitors can feel concepts in seven paintings by Henri Matisse, Salvador Dalí, Jackson Pollock and Marcel Duchamp.

The tactile objects were developed by art educators who are also active artists, after meticulous studies of the work of art and literature about the artist. One of the paintings represented is Matisse’s Apollo from 1953. It is considered as one of his last great works and depicts the sun god Apollo:

The painting apollo by Henri Matisse. A face in the center depicts the sun god Apollo. Sweeping lines form the shape of a heart.

The tactile version of this picture makes it possible to feel the face and the sweeping lines forming the shape of a heart. It is using the same colors as the original to aid partially sighted in experiencing the painting. Looking closely at the the tactile object reveal lines that are raised approximately 0.5 centimeters to enable exploration by hand.

Part of the face of Apollo in a paitning by matisse. Lines are raised 0.5 centimeters.

Another interesting feature is that the material used has a different temperature depending on the color. The blue parts feel much colder compared to the red parts. This provides another dimension for those with complete vision loss.

A part of the painting The Engima of William Tell by Salvador Dalí has been represented in a plaster cast. The original depicts Lenin’s protruded buttock being held by a crutch but the tactile object has focused on his foot in the lower part of the painting.

A part of the painting Enigma of William Tell depicting a foot and two nuts about to be crushed.
A tactile object of a foot and two nuts. One of the nuts is open and shaped in the form of a crib in which a small baby is sleeping.

The object contains part of the foot and two nuts visible in the lower part of the painting. In one of the nuts is a model of Gala, Dalí’s wife, which is hard to see in the painting. This is more apparent in the tactile object:

A three dimensional object representing a part of a foot and two nuts.

Is it a different experience?

Tiina Nummi-Södergren, head of the Swedish Association of the Visually Impaired sums it up:

You can never replace the lack of vision, but you can try to enable participation as much as possible. If you and I visit a botanical garden we will not experience it in the same way. I will be influenced by what I touch, smell and hear. My inner image will be different from your’s. But noone can say that my experience will be so small that it doesn’t matter.

References

]]> http://www.standards-schmandards.com/2006/accessible-art/feed/ 6 New tools in the making: Accessibility Analysis in Rails http://www.standards-schmandards.com/2006/accessibility-analysis-in-rails/ http://www.standards-schmandards.com/2006/accessibility-analysis-in-rails/#comments Mon, 03 Jul 2006 10:49:13 +0000 http://localhost:8888/?p=33 I am working on an accessibility analysis kit which you will be able to use as part of an automated test procedure in Ruby on Rails. RAAKT is a Ruby port of PAAKT (the Python Accessibility Analysis Kit) and can be used for assessing basic accessibility of HTML documents.

]]> I am working on an accessibility analysis kit which you will be able to use as part of an automated test procedure in Ruby on Rails. RAAKT is a Ruby port of PAAKT (the Python Accessibility Analysis Kit) and can be used for assessing basic accessibility of HTML documents.

Currently I am working on an accessibility analysis kit which you will be able to use as part of an automated test procedure in the Ruby on Rails framework. RAAKT is a Ruby port of PAAKT (the Python Accessibility Analysis Kit) and can be used for assessing basic accessibility of HTML documents. The focus is on machine measurable aspects which means that there is a huge disclaimer with regards to content. Just because you pass all tests in RAAKT does not mean you are completely accessible. It will, however, be possible to get a feel for basic accessibility issues in your web application. The idea is to make it possible to integrate RAAKT into your automated functional testing framework.

]]> http://www.standards-schmandards.com/2006/accessibility-analysis-in-rails/feed/ 6 Evaluation of WYSIWYG-editors http://www.standards-schmandards.com/2006/wysiwyg-editor-test/ http://www.standards-schmandards.com/2006/wysiwyg-editor-test/#comments Fri, 03 Mar 2006 23:37:46 +0000 http://localhost:8888/?p=32 Inline visual editing components (WYSIWYG-editors) provide the foundation for most content management systems. Therefore it is important that they provide functionality that enable content editors to create structured markup. In this article we take a look at seven popular editors and test them to see if they can be used to create basic accessible markup. Update: included results for eWebEditPro.

]]> Web based editing tools are becoming standard issue in modern content managment systems. As more and more organizations discover the advantages of using strucured markup it is important that these editing tools allow editors to markup content without knowledge of HTML. Unfortunately, many of the WYSIWYG-editing tools in use today create invalid markup or do not have the functionality required. Therefore I have selected some web based editing tools and tried to create a sample document in each of them.

Test method

I have selected test criteria based on commonly found content types and their requirements on markup. The test criteria are in the form of a sample document which contains headings, lists, tables and other types of content. Each tool has been used to create the sample document after which the created markup has been inspected. No features for visual formatting has been tested. These are rarely needed as formatting usually is done in a site-wide stylesheet.

Most of the tools can be configured with custom buttons and/or schemas to create specific markup. In this test the official demo version has been used.

Please not that this test is about web based editors (hosted in a browser window). This does not include Dreamweaver, Fronpage and similar tools. The selected tools (and their respective licensing type) are:

  1. EditOnPro by Realobjects. Commercial license.
  2. XStandard by Belus Technology. Commercial license. Lite version free.
  3. Kupu by OSCOM (et al). Open source (BSD-style license). Currently the default editor in Plone.
  4. FCKeditor by Frederico Caldeira Knabben. Open source (LGPL), commercial license available.
  5. CuteEditor by Cute Soft. Commercial license.
  6. JXHTMLEdit by Tecnick. Open source.
  7. TinyMCE. Open source (LGPL).
  8. Ektron eWebEditPro. Commercial license.

Test result

The total score for each editor is listed below. For test result details see here.

Editor Score (out of 19)
EditOnPro 16
XStandard 14
eWebEditPro 14
CuteEditor 14
TinyMCE 13
FCK-editor 9
JXHTML-Edit 7
Kupu 6

If you find error in the results, please leave a comment or send an e-mail to peter at standards-schmandards.com.

EditOnPro and XStandard seem to be the most advanced editors. They do not rely on cleanup routines or built in browser functionality which ensures consistency between different browser containers. Also, using real XML makes them suitable as a platform for future content management requirements. EditOnPro can be extended with custom schemas and can thus be used as a generic markup editor for specialized content. EditOnPro is a java applet which compared to XStandard makes it load more slowly.

Although CuteEdit and eWebEditPro scored well,they have some drawbacks. Creating table headers involves creating a table and then applyting headers thorugh a separate dialog (in the case of CuteEdit it involves right-clicking a cell, selecting “Verbs” and then “Change to header cell”). This may be too cumbersome for editors to do. And it seems impossible to do this when running CuteEdit in Firefox 1.5.

FCK-editor creates different markup depending on which browser is hosting the editor. Nested lists get the correct markup if you run FCK-editor in Internet Explorer, but not in Firefox. Developers would expect the same behaviour from a component that claims cross-browser compatibility.

TinyMCE scored best among the open source editors. It has functionality to set the lang attribute and title for most elements. Unfortunately it has poor handling of nested lists and I could not find a way to create table captions. These issues should be easy to fix so maybe a future version will provide better functionality.

JXHTMLedit crashed twice in Firefox 1.5 and sometimes display artifacts were left after deleting content.

Observations

Many of the tools have a toolbar with icons for various markup needs. Some common mistakes in the toolbar are:

  • The icon to create a blockquote looks like it will increase the left margin. This may lead editors to use incorrect markup to format their text.
  • Icons for items rarely used (such as justified text, subscript, superscript, underline and strikethrough) are available instead of icons for more commonly used markup such as blockquote, quote and acronym.
  • Most of the editors provide extensive customization options. EditOnPro can be set up with a specific schema to enable creation of custom tags.

Recommendations to WYSIWYG-editor developers

Some fundamental things that all editors should consider:

  • Remove toolbar buttons for rarely used markup items such as justified text (justified text on the web is bad for readability).
  • The default installation should provide buttons or menu options for inline quotes, blockquotes and acronyms.
  • When creating a table, headers should be created by default instead of forcing the user to add them later. Throw in a default caption as well to make sure content editors do the right thing.
  • Make sure images without alt-text specified receives an empty alt attribute.
  • Do not use the icon for “indent left” for blockquote markup.
  • If you claim cross-browser compatibility, make sure that the generated markup is identical.
  • Create valid markup

References

]]> http://www.standards-schmandards.com/2006/wysiwyg-editor-test/feed/ 113 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 Tips for improved accessibility in ASP.NET 1.1 http://www.standards-schmandards.com/2005/accessibility-in-aspnet/ http://www.standards-schmandards.com/2005/accessibility-in-aspnet/#comments Tue, 16 Aug 2005 21:20:23 +0000 http://localhost:8888/?p=10 If you are an experienced ASP.NET developer but new to accessibility you may have searched the web for ASP.NET accessibility information. It is likely that most of your results have been about how ASP.NET 2.0 promises improved standards support and better accessibility. But 2.0 isn't here yet. In this article we have a look at what you can do right now to increase accessibility in ASP.NET 1.1 web applications.

]]> If you are an experienced ASP.NET developer but new to accessibility you may have searched the web for ASP.NET accessibility information. It is likely that most of your results have been about how ASP.NET 2.0 promises improved standards support and better accessibility. But 2.0 isn’t here yet. In this article we have a look at what you can do right now to increase accessibility in ASP.NET 1.1 web applications.

Searching for information on how you can increase accessibility in ASP.NET will give you a lot of information on ASP.NET 2.0 (Whidbey) features. It is like Microsoft is trying to hide the fact that the first generation of ASP.NET has issues with accessibility and standards compliance.

Anyway, all is not lost. Here are some tips on what you can do right now to increase accessibility in your existing ASP.NET 1.1 applications. If you are an experienced ASP.NET developer, but new to the field of accessibility make sure you check out some of the other articles here.

1. Try to create standards-compliant pages

If you are using the W3C validator to validate your ASP.NET pages you will notice that no matter what you do in Visual Studio .NET 2003 they will not validate. This is because ASP.NET will ouput hidden HTML to manage view state. However, it is possible to rewrite the output before it reaches the browser. This of course has some impact on performance but if you are using your output cache correctly the performance hit will be of minor importance. There are several ways to rewrite output to make it standards compliant:

  1. A C# class to make your ASP.NET pages XHTML valid. A short tutorial with code samples.
  2. Valid XHTML within .NET.
  3. Ensuring XHTML compliancy in ASP.NET
  4. Producing XHTML-Compliant Pages With Response Filters
  5. XhtmlWebControls.NET. This is a commercial product. It is a rewrite of all the web controls to make sure they are Xhtml 1.1 compliant.

If you decide to not use any of the above you can still make sure that your web pages use proper semantic markup. You can still use the W3C validator to check for other validation errors. If your application can’t be reached from the internet you can use the Web developer toolbar Firefox extension to validate single pages. If you are working on a large scale project you can set up a validation server and automate testing (instructions in my previous post “Validating an entire site“.

2. Update to .NET Framework 1.1 Service Pack 1

Service pack 1 includes an important update of the datagrid control enabling output of real table header elements and table captions. After the upgrade you can set the UseAccessibleHeader property to true and your datagrid will use the <th> element for the grid headers.

This service pach also contains a fix for the asp:label control. More on that below.

3. Use real labels for your form fields

When designing web pages in Visual Studio .NET 2003 it is easy to quickly set up a web page with form fields. However, using the asp:label control to create field labels is bad as it will be translated to a simple <span> element. You are better off writing the HTML for the label yourself as the visual designer will give you no help. Switch to the HTML source view and use the following code to create a label for your form element:

<label for="<%=TextBox1.ClientID%>">My label text:</label>

You may wonder what the “TextBox1.ClientID” is doing there. As you may know, ASP.NET creates a unique id for all elements that have the attribute “runat=server”. So, to make sure your label is properly connected to your form field you can use “TextBox1.ClientID” which will be translated to the rendered client id of your TextBox1 field.

If you have applied Service Pack 1 you can use the AssociatedControlId property of the asp:label element and get the same result.

4. Do not rely on client-side validation

ASP.NET enables you to easily add client side validation to forms. This method relies on javascript and will be hard to use for vision impaired users (see previous discussion on AJAX and accessibility). It is likely that they will not get any information at all about validation errors. You can still use the server side validation functionality of ASP.NET. Make sure you present your validation errors in an accessible way.

If you have any more tips you feel would be valuable for ASP.NET developers, please post them below.

]]> http://www.standards-schmandards.com/2005/accessibility-in-aspnet/feed/ 5