Group items tagged

Personally I have several reasons for advocating Web accessibility. First of all an idealistic one: I want everybody to be able to use the Web. I am not disabled (yet), so I can (and am often forced to) muddle through sites that are badly built, but a person with a disability may not be able to. Since it is possible to build sites that almost everybody can use, I don’t see why we shouldn’t. Then a few reasons that some may call selfish: I do not have any problems related to motor skills, but I have a really hard time using dropdown and flyout menus, especially hierarchical ones, as well as phony Flash or JavaScript scrollbar imitations. Accessible sites in general either do not contain such obstacles or provide ways around them. Despite having no substantial eyesight problems, I find reading tiny text (below 11px is tiny to me), low contrast text, and reading any size high contrast, light-on-dark text to be very straining. A website designed with accessibility in mind is less likely to cause legibility problems for me. I like being able to use my keyboard to navigate websites. Accessible sites are keyboard friendly since they do not force people to use a mouse.

Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification: The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute. Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work… Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy. I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results. Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order. JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus. The only screen reader of those that I tested that does handle multiple labels is Fire Vox. The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.

WysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it. We are giving developers early access to the project while we continue to work out the remaining issues. Note: It’s extremely early. Contributors are welcome so please check out the project on GitHub and send us your feedback.

Christian asks what would be the open-source equivalent of AIR? XUL says Ian. Christian says that AIR is built on HTML, CSS and JavaScript so once the player gets keyboard access it will be quite accessible. Ian responds that he looked on the Adobe site for accessibility info on AIR and the fact that he found nothing scared him.

3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.

7. Rich design and multimedia. This is Flash, so ideal for highly customized UIs, animation, sound and video. Adobe is proving the point by creating a media player built with AIR. Existing Flash developers can easily use their skills to build AIR applications.

4. Proprietary technology. AIR applications depend on Adobe’s runtime.