Weblogs: Web Accessibility

FormCamp: Day 2

Wednesday, January 17, 2007

FormCamp is now over, and I'm back in the UK. One dozen front-end developers and designers - most handpicked by the organiser, collaborating on laying a foundation that will make creating of accessible and standards compliant forms easier for the rest of us. We hit a few issues, and uncovered some truths in our weekend retreat in Munich.

Sharing accessibility experience

Among the attendees at FormCamp were Angie Radtke and Jörn Hofer - both very experienced in web accessibility, and both brought a wealth of practical knowledge of the subject. Although I've been thinking and writing about web accessibility for over six years, there were still ideas out there I hadn't been aware of before.

Angie works on Joomla!, and co-author of Barrierefreies Webdesign about accessible web design. Jörn is an experienced web developer and one of the sites he produced made the BIENE shortlist (and won one, so to did Wolfgang Wiese, another FormCamp attendee, winning a gold one in 2005) - so to did Wolfgang Wiese, who was also at FormCamp). (I recall Jeremy Keith was one of the judges.)

Both developers work alongside screen-reader users - and some of their findings are very interesting, like using a paragraph element to wrap a form-field and label instead of a generic division improves the reading of the form - because there is a pause at the end of the paragraph. This is a clever example of a screenreader supporting the semantic meaning of elements.

Semantic understanding of forms

We split into two working groups, and the group discussing the semantic usage of form elements included luminaries like Jens Meiert, Angie Radtke, Gerrit van Aaken, Jens Grochtdreis, Jörn Hofer leading the discussion. What came out of it were a series of modules covering typical single question structures. These provide excellent base examples of the markup needed to create a structurally and semantically appropriate form elements.

The inevitable discussion came up about whether the correct wrapper is a paragraph or a generic div, and the overall conclusion is that the div element was the most appropriate, despite the useful behaviour of the p for screenreaders.

Form styling

Near the end, we had a long discussion with Gerrit about the problems designers face with styling form elements. The legend element is a particularly unmalleable element in the current crop of browsers (especially in Internet Explorer 6). But it has a well defined and well supported use in forms, for example as a semantic wrapper for radio button groups as well as grouping together related input elements (for example, personal details).

The legend element needs to be there, and the base examples delivered do have this element - and they need to be there in the document when it is finally rendered to a browser.

One of the barriers we front-end developers have to tackle is the belief that online forms must exactly match their print counterparts. Printed forms are optimised for page size, and this optimisation does not fit neatly into websites. We have to demonstrate correct semantic usage if we are to ensure forms are as usable as possible to our audience. We have to refrain from making those anti-semantic changes that degrade the accessibility of a form, refrain from making those compromises to satisfy the design requirements of an application. It simply is a case of when the semantic structure of the form conflicts with the design requirement, the design is broken or not fit for purpose.

One interesting way forward is to offer a form design resource that showcases elegant styling of forms - like a forms zen garden. Starting with a correctly structured and semantically descriptive markup - with a few extra styling hooks, and encourage the web standards aware designers to demonstrate their remarkable talents in this most difficult and challenging aspects of web design.

Validating forms

The other working group, comprising myself, Christian Heilmann, Timo Derstappen, Dirk Ginader built a form validation framework. The key feature is having one set of validation rules that could be used both in the browser and on the server. We started off with a JSON data structure that defined some validation rules for each field, and build prototypes in PHP and JavaScript to demonstrate the idea was feasible.

The harder part of the problem was displaying the validation messages in an accessible manner. The JavaScript validator benefited from using the focus event handler to ensure that the user was taken through all the fields in error. Unfortunately our test cases failed to work for keyboard users - setting the focus on the label or input field failed to give keyboard users immediate access to the field, and resulted in some weird tab order bugs. One solution we got working was to use internal named anchors as destination points. Its ugly, but it works.

Unfortunately the same technique cannot be reliable used when server-side validation is used. Using links to guide the navigation through a form fails on the grounds that the screenreader in forms mode only sees form elements, and so the links are ignored.

We build two ways of reporting errors. The inline method adds the error message into the field label (or legend it that's the more appropriate place). That way a screen reader would hear the message when they are at a form field that requires correction. The second method was to list all the error messages in a list at the very start of the form, each message linked to the form field that flagged the error.

In both cases we updated the title of the page to immediately indicate a validation message had been flagged and needed correction. We also put a message at the very top of the document that announced a validation error had occurred and provided a link to the first field in error, or the list of error messages - depending on the reporting errors technique used.

Where to next?

So we've made a start into defining best practice methods of creating usable and accessible forms. We have working code that demonstrates validating on both client and server from the same set of rules. The work is now ongoing within the Webkrauts mailing lists to improve the work we've done so far. The intention is to publish the work under an Open license for other people to benefit from and use.

Thank you to everyone who came to FormCamp. Thanks particularly to Jens Grochtdreis and Holger Haslbeck for a well organised event. And being the only non-German speaker there, thanks to everyone for making me feel included - the entire event was done in English for my benefit. I made a dozen more friends and colleagues. Dankeschön!

Other commentary

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]