The Tink Tank » Web life http://tink.co.uk Mon, 23 Jan 2012 20:45:54 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Using the HTML5 nav element http://tink.co.uk/2011/12/using-the-html5-nav-element/ http://tink.co.uk/2011/12/using-the-html5-nav-element/#comments Wed, 28 Dec 2011 18:44:21 +0000 Léonie Watson http://tink.co.uk/?p=331 HTML5 introduces the nav element for marking up sections of a page that contain navigational links. Used wisely the nav element is a big help to screen reader users, as well as a step forward in semantic meaning.

HTML4 navigation

With HTML4, a typical navigation block might look like this:

<div>
<ul>
<li><a href=”home.html”>Home</a></li>
<li><a href=”about.html”>About us</a></li>
…
</ul>
</div>

Using a screen reader it would be possible to move through a page that uses this approach, and access the navigation without difficulty. One strategy might be to use your screen reader’s shortcut key for moving from one div on the page to the next.

The drawback is that to a screen reader, one div looks pretty much like another. There isn’t any semantic information that a screen reader can use to inform you about the purpose of the content you’re dealing with.

This is where the nav element comes in. Here’s what the HTML5 specification says about the nav element:

“The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.”

HTML5 navigation

So the same navigation block in HTML5 might look like this:

<nav>
<ul>
<li><a href=”home.html”>Home</a></li>
<li><a href=”about.html”>About us</a></li>
…
</ul>
</nav>

The nav element makes it possible for screen readers (and other user agents) to identify the purpose of the content. NVDA 2011.3 already does this. It won’t be long before other screen readers also support the nav element, but in the meantime you can use ARIA landmark roles to achieve the same effect:

HTML5 navigation with ARIA

Adding the ARIA navigation role to the nav element is a useful belt and braces technique.

<nav role=”navigation”>
<ul>
<li><a href=”home.html”>Home</a></li>
<li><a href=”about.html”>About us</a></li>
…
</ul>
</nav>

When to use the HTML5 nav element

Use the nav element wisely. The HTML5 specification isn’t too prescriptive, but instead offers the following guidance:

“Not all groups of links on a page need to be in a nav element – the element is primarily Intended for sections that consist of major navigation blocks.”

Using the nav element too often will rapidly reduce the benefit to screen reader users. In the same way that one div looks like another to a screen reader, so does one nav element to the next. Using the nav element to mark up just one or two key navigation blocks helps keep those sections semantically distinct from the rest of the page.

To highlight this, the HTML5 specification gives the following example:

“… it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.”

Use the nav element to mark up the primary (site) navigation block. If a secondary (page) navigation block is needed, use the nav element here as well.

Otherwise, it’s your judgement call as to when you use the nav element. Just remember that screen reader users will benefit most when the nav element is used lightly, and that doing this won’t have a negative impact on other people either.

]]> http://tink.co.uk/2011/12/using-the-html5-nav-element/feed/ 0 Using HTML5 headings http://tink.co.uk/2011/11/using-html5-headings/ http://tink.co.uk/2011/11/using-html5-headings/#comments Mon, 28 Nov 2011 23:46:51 +0000 Léonie Watson http://tink.co.uk/?p=319 HTML5 headings make it easy to syndicate and reuse content, without breaking the heading hierarchy. Using HTML5 headings and keeping the heading hierarchy backwards compatible proves unexpectedly complicated though. The HTML5 specification has a solution, but is it the right one?

HTML5 sections

HTML5 uses sectioning content to break a page up into chunks. The <article>, <aside>, <nav> and <section> elements can be used to explicitly create sections. Here’s what the HTML5 specification says about sectioning content:

Sectioning content is content that defines the scope of headings and footers… Each sectioning content element potentially has a heading and an outline.

HTML5 headings

This means that each section contains its own heading hierarchy. Here’s what the HTML5 specification says about it:

The first element of heading content in an element of sectioning content represents the heading for that section.

This means that you could use an h1 at the start of each sectioning element. For example:

<body>
<h1>Favourite colours</h1>

	<section>
	<h1>Purple</h1>
	<p>Purple is my favourite colour.</p>

		<aside>
		<h1>Reasons</h1>
		<p>I like purple because…</p>
		</aside>
	</section>

	<section>
	<h1>Pink</h1>
	<p>Pink is my least favourite colour.</p>

		<aside>
		<h1>Reasons</h1>
		<p>I dislike pink because…</p>
		</aside>
	</section>

</body>

HTML5 calculates the rank of each heading based on its location within the sectioning content elements. The above example would therefore have the following structure:

1. Favourite colours
1.1. 	Purple
1.1.1. 			Reasons
1.2. 				Pink
1.2.1. 						Reasons

If the same page were to be coded with semantically correct HTML4.01, it might look something like this:

<body>
<h1>Favourite colours</h1>

	<div>
	<h2>Purple</h2>
	<p>Purple is my favourite colour.</p>

		<div>
		<h3>Reasons</h3>
		<p>I like purple because…</p>
		</div>
	</div>

	<div>
	<h2>Pink</h2>
	<p>Pink is my least favourite colour.</p>

		<div>
		<h3>Reasons</h3>
		<p>I dislike pink because…</p>
		</div>
	</div>

</body>

The idea is that the HTML5 heading hierarchy is adaptable. You could pull out the <section> elements and slot them into another HTML5 website, without breaking the heading hierarchy.

HTML5 explicit and implicit headings

Things get a touch more involved when you create a heading hierarchy within a single section. The HTML5 specification goes on to say:

The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new or implied sections. Headings of lower rank start implied sub sections that are part of the previous one.

This means that if you use nested headings within the same section, HTML5 will behave as though they’re explicit sub sections. For example:

<body>
<h1>Favourite colours</h1>

	<section>
	<h1>Purple</h1>
	<p>Purple is my favourite colour.</p>

		<h2>Reasons</h2>
		<p>I like purple because…</p>
	</section>

</body>

In the above example the <aside> element has been removed, so that section is no longer explicitly defined. The “Reasons” heading is of lower rank than the “Purple” heading though, so HTML5 implicitly assumes there is a sub section there anyway. The outline would look like this:

1. Favourite colours
1.1. 	Purple
1.1.1. 			Reasons

If the “Reasons” heading had been an h1 instead, HTML5 would automatically close the explicitly defined <section> and open an implicitly defined section at the same level. For example:

<body>
<h1>Favourite colours</h1>

	<section>
	<h1>Purple</h1>
	<p>Purple is my favourite colour.</p>

		<h1>Reasons</h1>
		<p>I like purple because…</p>
		</section>

</body>

The resulting outline structure would therefore be:

1. Favourite colours
1.1. 	Purple
1.2. 	Reasons

Using h1 only or explicitly ranked headings

If you wanted to conform to the HTML5 specification, and there was no need to provide backwards compatibility, the h1 only technique would be the best.

It’s going to be some while before we reach that utopia though. In the meantime, developers can use explicitly ranked headings to support the browsers and assistive technologies that haven’t implemented HTML5 headings at all. Here’s what the HTML5 specification has to say on the subject:

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

This means that the following HTML5 examples would both represent the same outline structure.

Using h1 only

<body>
<h1>Favourite colours</h1>

	<section>
	<h1>Purple</h1>
	<p>Purple is my favourite colour.</p>

		<aside>
		<h1>Reasons</h1>
		<p>I like purple because…</p>
		</aside>
	</section>

</body>

Using explicitly ranked headings

<body>
<h1>Favourite colours</h1>

	<section>
	<h2>Purple</h2>
	<p>Purple is my favourite colour.</p>

		<aside>
		<h3>Reasons</h3>
		<p>I like purple because…</p>
		</aside>
	</section>

</body>

The outline structure represented by both of the above examples would be:

1. Favourite colours
1.1. 	Purple
1.1.1. 		Reasons

HTML5 heading support

At the moment Jaws 13 supports the h1 only technique in Internet Explorer 9 and Firefox. No other screen readers support HTML5 headings at all.

It’s worth noting that as of Jaws 13.0.527, explicitly ranked HTML5 headings are completely broken in both Firefox and Internet Explorer. It takes the rank of the heading and the sectioning content hierarchy in conjunction, and the result is an extremely broken heading hierarchy.

Choosing h1 only or explicitly ranked headings

The question has been asked whether the h1 only or explicitly ranked headings technique is the best one to use.

The HTML5 specification clearly encourages the h1 only technique. The difficulty is that withbrowsers and screen readers that don’t support HTML5, the heading hierarchy is flattened out completely.

Using explicitly ranked HTML5 headings solves the flat heading hierarchy problem. The likelihood is that using this more complicated technique will result in even fewer pages with a meaningful heading hierarchy though.

My suggestion would be to use the h1 only technique unless you’re absolutely sure you’ve got your head around the way explicitly ranked headings work in HTML5. Jason Kiss recommends a different approach, and it’s good advice as well. Here’s my take on things though.

A flat heading structure certainly isn’t ideal. It’s considerably better than the (usually broken) HTML4.01 heading structures you find on every other website at the moment though.

In time browsers and other screen readers will adopt support for the h1 only technique. When they do, we’ll probably have the best chance of semantically correct, logical and usable heading hierarchies since HTML was created!

]]> http://tink.co.uk/2011/11/using-html5-headings/feed/ 2 Design like you give a damn! http://tink.co.uk/2011/09/design-like-you-give-a-damn/ http://tink.co.uk/2011/09/design-like-you-give-a-damn/#comments Sat, 17 Sep 2011 14:30:25 +0000 Léonie Watson http://tink.co.uk/?p=306 Inclusive design is an aspirational concept. It isn’t particularly inspirational though. Inclusive design is a phrase for client meetings and government papers. No harm in that, but it isn’t a phrase that rocks the world and inspires us to challenge the accepted status quo.

Inspiration comes courtesy of an old school friend, founder and CEO (Chief Eternal Optimist) of Architecture for Humanity. His philosophy? Design like you give a damn!

It’s a philosophy to change the world by. It’s a mantra that is as relevant in the digital world as it is in the physical. It’s a clarion call to anyone who believes things need to change, and that together we can do it!

Design like you’re Banksy. Read the rule book, then rip it up and create something that challenges the accepted wisdom.

Design like you’re Da Vinci. Be curious about everything, and never stop questioning how you can make things better.

  • Design like you’re Chanel. Strive for beauty and elegance, but understand that those things will not be the same for everybody.

    • Design like you’re Brunel. Know that planning is important, but that imagination makes the extraordinary possible.

    Be bold, be disruptive, be innovative, be inclusive. Be whatever you want to be. But whatever you do, let’s get out there and design like we give a damn!

    ]]>     http://tink.co.uk/2011/09/design-like-you-give-a-damn/feed/ 0     Screen readers, ARIA roles & HTML5 support http://tink.co.uk/2011/09/screen-readers-aria-roles-html5-support/ http://tink.co.uk/2011/09/screen-readers-aria-roles-html5-support/#comments Wed, 07 Sep 2011 22:35:02 +0000 Léonie Watson http://tink.co.uk/?p=299 Several screen readers now support ARIA landmark roles. Some screen readers such as NVDA and Jaws are also improving support for HTML5 elements. This means that it’s important to put your ARIA roles in the right place.

    It’s increasingly common to find landmark roles applied to HTML4 documents. They’re extremely useful to screen reader users, who can use them to navigate around a page and understand the purpose of different areas of content.

    A simple example is role=”navigation”. It might be applied like this:

    <div>
    <ul role=”navigation”>
    …
    </ul>
    </div>

    With NVDA and Jaws you can move from one landmark role on a page to the next using a shortcut key. Both screen readers behave similarly when they encounter a landmark role. Using the example above, they would announce “Navigation landmark” on reaching the list.

    So far, so good. With the move to HTML though, the code example might evolve into something like this:

    <nav>
    <ul role=”navigation”>
    …
    </ul>
    </nav>

    In slightly older screen readers this transition makes no difference. The <nav> element is effectively ignored, and the navigation role behaves exactly as expected. There’s a bit of a problem though.

    The introduction of HTML5 support for elements such as <nav> means that both Jaws and NVDA now treat the above code exactly as they should. In other words, they both behave as though two navigation landmarks were present in quick succession. The result is that screen reader users hear “Navigation landmark navigation landmark”, which isn’t a great user experience.

    Logically, the answer is to remove the role=”navigation” from the code entirely:

    <nav>
    <ul>
    …
    </ul>
    </nav>

    The trouble is that this removes the role for anyone using a slightly older version of either screen reader. Happily the solution is straight forward. Apply the role to the element it maps to:

    <nav role=”navigation”>
    <ul>
    …
    </ul>
    </nav>

    Current versions of NVDA and Jaws will announce the landmark once, and so will the slightly older versions that have ARIA support but not HTML5. It isn’t quite the minimalist approach many would prefer, but it’s currently the one that delivers the best experience for screen reader users.

    ]]>     http://tink.co.uk/2011/09/screen-readers-aria-roles-html5-support/feed/ 2     Marking up the current page with HTML5 links http://tink.co.uk/2011/07/marking-current-page-html5/ http://tink.co.uk/2011/07/marking-current-page-html5/#comments Sun, 31 Jul 2011 10:17:04 +0000 Léonie Watson http://tink.co.uk/?p=290 When you’re browsing a website using its primary navigation, it’s helpful to know which page you’re on, and which pages you can go to. HTML5 makes it simple to do this, but the technique moves away from a common approach used in HTML4.01.

    When you’re looking at a website’s navigation, the current page should be visually distinct from the other pages. When you’re using a screen reader, the separation needs to be programmatic rather than visual.

    A common technique used with HTML4.01 is to use the <strong> element to markup the current page:

    <ul>
    <li><a href=”home.html”>Home</a></li>
    <li><strong>About us</strong></li>
    <li><a href=”contact.html”>Contact us</a></li>
    …
    </ul>

    This had the advantage of creating both the visual effect and the programmatic effect needed to differentiate the current page from the rest.

    The HTML5 specification subtly changes the purpose of the <strong> element though. Instead of marking up content with strong emphasis, it should be used to markup content of strong importance. More on this (and other similar changes) within the HTML5 spec can be found on the HTML5 Doctor website.

    This change in the specification probably doesn’t make it wrong to use the above technique, since it could be argued that the current page is something of strong importance. It is one of those potentially murky areas though, and besides, the HTML5 spec recommends a much cleaner approach instead.

    If the a
    element has an href
    attribute, then it represents a hyperlink
    (a hypertext anchor).

    If the a
    element has no href
    attribute, then the element represents
    a placeholder for where a link might otherwise have been placed, if it had been relevant.

    In other words you can strip out all the usual attributes from the <a> element, to turn it into a placeholder instead:

    <ul>
    <li><a href=”home.html”>Home</a></li>
    <li><a>About us</a></li>
    <li><a href=”contact.html”>Contact us</a></li>
    …
    </ul>

    As far as the screen reader is concerned, the current page link is deactivated. This provides the separation needed to understand which page you’re on, and which pages you can go to. To create the same separation visually, you can apply a CSS class that gives the current page a different appearance from the other links within the navigation.

    ]]>     http://tink.co.uk/2011/07/marking-current-page-html5/feed/ 3     Text descriptions and emotion rich images http://tink.co.uk/2011/06/text-descriptions-emotion-rich-images/ http://tink.co.uk/2011/06/text-descriptions-emotion-rich-images/#comments Fri, 03 Jun 2011 13:10:20 +0000 Léonie Watson http://tink.co.uk/?p=278 This article was first posted in 2007 on the eAccess blog. Three years later and I still believe that emotion rich images are important to blind people, particularly those who once had sight (and that’s most of us). Results from the third WebAIM screen reader survey suggest I’m not alone, so I’m reposting the article here to encourage the debate to continue.

    So just what is a decorative image? It seems to me that one person’s eye candy is another person’s emotional link to a website.

    For some, decorative images are those horizontal rules, bullets and other forms of minor clipart we find sprinkled around the web. For others, the term
    is wider ranging. It includes more content rich images such as photos and artwork.

    So, you might ask, what’s the problem with this varied point of view? The answer is simple. Alt texts.

    If you Google for the term “decorative image + alt texts”, you’ll come across countless sites that suggest that a decorative image be
    given a null alt text. It’s possible that we can all agree that for minor forms of clipart, a null alt text will do nicely. But it gets a little
    more difficult when it comes to more complex images.

    I’m not talking about diagrams, blueprints or other information rich images. There’s no argument that they should always carry an alt text,
    possibly even a long description. I mean the vibrant, emotion rich images that provide a website with a sense of atmosphere.

    It’s sometimes argued that providing such images with descriptive alt texts provides too much “noise” for a screen reader user. If we
    screen reader users stopped to listen to every alt text, every time we came across an image, then this assumption would probably be right. But I’ll
    let you into a secret. We won’t.

    Like sighted users, we’ll skip around the content of the page until we find something that interests us. If the first few syllables of an alt text
    sound promising, we’ll pause to read. If they don’t, we’ll move on to the next element on the page. Also like sighted users, we’re
    often likely to pause on something unimportant, but which captures our imagination.

    A good alt text can conjure up wonderfully stimulating mental images. A friendly smile is the same in print, photo or wax crayon. Whether you listen to
    an image or see it, the emotional response is the key factor, so why should we recommend that these emotion rich images should be given a null alt text
    and hidden from screen reader users?

    Perhaps it’s time we introduced another group of images: Emotion rich images and encouraged the practice of providing descriptive alt texts for
    them. If people don’t want to listen to the alt text, they won’t. If people don’t want to pause and look at the image, they won’t.
    In either case, it’s good to have the choice.

    ]]>     http://tink.co.uk/2011/06/text-descriptions-emotion-rich-images/feed/ 4     Screen reader support for HTML tables http://tink.co.uk/2010/08/screen-reader-support-for-html-tables/ http://tink.co.uk/2010/08/screen-reader-support-for-html-tables/#comments Mon, 30 Aug 2010 13:03:32 +0000 Léonie Watson http://tink.co.uk/?p=161 Screen reader support for tables is something of a curiosity. Although tables are among the most common of HTML elements, they’re often misused and poorly coded. To some extent this has influenced screen reader support, but even so the variations in screen reader behaviour are quite remarkable.

    Possibly the biggest misuse of tables is using them to control page layout. Originally intended to markup tabular data, the concept of a layout table is now generally acknowledged.

    How do screen readers interact with tables?

    As explained in a Webaim article on creating accessible tables, screen reader users often struggle with tables. The mechanics of interacting with a table vary quite significantly between different screen readers.

    When focus is on a table, Window Eyes has two specific commands for entering/exiting tables mode (Control +/-). Once in tables mode, you can use Insert + arrow keys to move up/down or left/right from one table cell to the next.

    Jaws and NVDA have a slightly easier approach. Once a table has focus, the Control, Alt + arrow keys can be used to move through the table without entering into any kind of tables mode.

    When it comes to reading a table summary, there is a rare moment of consistency. Jaws, NVDA and Window Eyes all read the summary just after the table itself has been announced. VoiceOver also speaks the summary, but only once focus has paused on the table for a few seconds first.

    So when is a table not a table?

    No, not some kind of tabular existentialism, but a reasonably serious question. What are the characteristics of a layout table? If a table has only one row/column, is it really a table at all? How does a screen reader identify a data table anyway?

    Screen reader results

    Using a simple table test page and some help from Everett Zufelt, I put several popular screen readers through their paces in Firefox 3.6. The four screen readers were:

    • Jaws 11.
    • NVDA 2010.1.
    • VoiceOver OSX10.6.
    • Window Eyes 7.2.

    Each of the screen readers was tested using its default configuration. Jaws and Window Eyes both have advanced table customisation settings, but it’s questionable how often such settings are used. More on this later though.

    Single row/column tables

    All four screen readers agree that a single row/column table without a summary is a layout table. In other words, the table itself isn’t announced, and only the content is read.

    When a summary is introduced into a single row/column table, there’s a definite split amongst the screen readers. Jaws and Window Eyes continue to treat it as a layout table, whilst NVDA and VoiceOver both announce that a table is present before reading the content.

    Multiple row/column tables

    It’s when dealing with multiple row/column tables that the differences really start to appear. NVDA for example isn’t able to handle row/column headers at all. It’s a known bug that’s been partially fixed in the forthcoming 2010.2 release. NVDA will then be able to handle row/column headers in Firefox, but not in Internet Explorer.

    If a table has multiple rows/columns, Jaws treats it as a correctly marked up data table whether the row/column headers have been marked up or not. It automatically uses the upper row and left hand column cell content as header information.

    The table settings in Jaws mean you can switch to a more standards compliant interpretation of the code. The default assumption however, is that the table will not be marked up correctly and so Jaws fills in the gap on behalf of the user.

    Window Eyes takes the reverse approach. By default it ignores even correctly marked up row/column headers. You must first change the table settings in Window Eyes before any information is made available.

    Of the four, VoiceOver pays the closest attention to the code. Where the table has multiple rows/columns and no header markup, VoiceOver announces the table is present and simply reads the content.

    When row/column headers are introduced using the <th> tag, VoiceOver acknowledges the column headers but not those for the row. If the scope attribute is the only means by which the row/column headers have been marked up, VoiceOver doesn’t recognise them at all.

    With such a range of different behaviours, it’s enough to make you wonder whether it’s worth using/coding tables properly at all. The short answer is yes, it is.

    Screen readers and the web standards contract

    It comes down to the theoretical contract between access technology vendors and web developers. If accessibility is really going to succeed, the contract to support web standards must be upheld by both parties.

    Of the four screen readers covered here, VoiceOver probably comes the closest to supporting web standards when it comes to tables. Given its track record, there is every reason to think that NVDA 2010.2 will do the same when it’s released, albeit only in Firefox.

    Jaws and Window Eyes are the real conundrum however. Both are quite capable of standards support, but neither do it out of the box. Jaws at least behaves this way on the assumption that data tables won’t be properly marked up, and it’s difficult to argue with that for the time being.

    Right now, there is work that needs to be done on both sides as far as the web standards contract goes. There are still far too many badly marked up and confusing tables out there, and there is still much that screen readers could do to improve the way they interact with the good ones.

    The signs are encouraging though. A few versions back, Jaws didn’t have an option to switch to using marked up headers at all. When the feature was first introduced in 6.01 it briefly became the default setting, and perhaps in time Jaws will revert to this behaviour.

    NVDA and VoiceOver bring the greatest hope for a standards compliant web. Both were created in a time of standards awareness, and neither is held back by the millstone of legacy code and backwards compatibility.

    ]]>     http://tink.co.uk/2010/08/screen-reader-support-for-html-tables/feed/ 0     Screen Reader Support For Disabled & Read Only Form Fields http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/ http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/#comments Sun, 21 Feb 2010 16:12:52 +0000 Léonie Watson http://tink.co.uk/?p=146 Some while ago I was asked how screen readers handle disabled and read only form fields. Despite forms being commonplace on most websites, there’s remarkably little information available on the subject. It turns out that there’s also very little consistency in the way different screen readers behave either.

    The HTML 4.01 specification defines two attributes that can be used to prevent people from interacting with form fields:

    • disabled
    • readonly

    Both attributes are boolean, meaning they can either be on or off.

    Disabled Form Fields

    The disabled attribute can be applied to button, input, optgroup, option, select and submit form fields. For example:

    <input type=”text” disabled=”disabled” />

    When applied to a form field, the disabled attribute means that the field:

    • Should not receive focus.
    • Should be skipped in the tab order.
    • Should not successfully submit data.

    Read Only Form Fields

    The readonly attribute can be applied to input and textarea form fields. For example:

    <input type=”text” readonly=”readonly” />

    When applied to a form field, the readonly attribute means that a field:

    • Should receive focus, but cannot be modified by the user.
    • Should be included in the tab order.
    • Should successfully submit data.

    Screen Reader Results

    Using a simple forms test page, I looked at the way three popular screen readers dealt with disabled and read only form fields. It wasn’t meant to be an exhaustive investigation, but more a chance to get a flavour of screen reader support. The screen readers in question were:

    • Jaws 11.
    • NVDA 2009.1.
    • Window Eyes 7.11.

    To keep things even, I put each screen reader through its paces in two different browsers:

    • Firefox 3.6.
    • Internet Explorer 8.

    The results were extremely varied, with little consistency across either screen readers or browsers.

    All three screen readers correctly reported when a form field was disabled, except for Jaws in Firefox. For some reason, Jaws treats disabled textboxes and textareas as though they weren’t there in Firefox at all.

    There are slight differences in the way each screen reader reports a disabled form field. Jaws and NVDA both indicate the field is “Unavailable”, whilst Window Eyes reports that the field is “Disabled”.

    Things get a little more complicated with read only form fields. NVDA and Window Eyes treat read only textboxes and textareas as plain text, so don’t report them as read only fields. Jaws does treat them as form fields and reports them as “Read only”, with the exception of textareas in Firefox.

    Read only radio buttons are recognised as form fields by all three screen readers, but none of them correctly report them as “Read only”. To add to the confusion, read only buttons could be selected using all three screen readers.

    Jaws and NVDA both exclude disabled form fields from the tab order, whilst Window Eyes does not. Bear in mind that Jaws completely ignores disabled textboxes and textareas in Firefox, which isn’t quite the same as skipping them in the tab order.

    All three screen readers include read only radio buttons in the page tab order. In a reversal of the way disabled form fields are treated, Jaws and NVDA both include read only textboxes and textareas in the tab order, whilst Window Eyes does not.

    Generally speaking, NVDA treated disabled and read only form fields most consistently. It was also the most accurate in terms of following the HTML 4.01 specification.

    Window Eyes was reasonably consistent across both browsers, but didn’t follow the specification for disabled and read only fields particularly well. Jaws on the other hand seemed a little more true to the specification, but gave the most inconsistent results overall.

    If anyone would like to contribute results for other screen readers or can add more information to the above results, please drop me a line.

    ]]>     http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/feed/ 8     Contacting Organisations About Inaccessible Websites http://tink.co.uk/2010/01/contacting-organisations-about-inaccessible-websites/ http://tink.co.uk/2010/01/contacting-organisations-about-inaccessible-websites/#comments Thu, 07 Jan 2010 21:46:18 +0000 Léonie Watson http://tink.co.uk/?p=140 Contacting an organisation to explain why you find their website difficult to use, can seem a bit daunting. Who should you talk to? What should you say? How should you approach it?

    Contacting Organisations About Inaccessible Websites is a splendid new resource from the Web Accessibility Initiative (WAI).

    People who are familiar with web accessibility will have no trouble contacting an organisation. They’ll happily get up close and technical with anyone they can find.

    If that isn’t you though, don’t worry. Contacting Organisations About Inaccessible Websites has everything you need. Here’s what it has to say about why feedback is important:

    Your feedback to an organization can help improve the accessibility of websites for you and many other people who use the websites. Website owners have many priorities for changes and improvements, and the more an organization hears about accessibility from people who use their website, the more likely it is that accessibility will become a higher priority.

    With that in mind, the document goes on to give practical advice on the following topics:

    • Considering your approach.
    • Identifying key contacts.
    • Describing the problem.
    • Including sources for more information.
    • Requesting a reply.
    • Following up as needed.

    If you’re still feeling a little cautious, an email template is provided. Some example emails are also included, to give you an idea of how to go about things.

    There’s one further piece of advice in the document. Actually, I think it’s the most important piece of advice of all, so I’m going to repeat it here:

    Consider also contacting organizations that do a good job of making their websites accessible and easy to use by people with disabilities and older users, to acknowledge and encourage their efforts.

    Sometimes, the accessibility of a website is due to the organisation’s policy. More often, it’s down to a small band of accessibility champions making the case as best they can. In either case, receiving positive feedback can only re-enforce the message and encourage them to keep building in accessibility.

    ]]>     http://tink.co.uk/2010/01/contacting-organisations-about-inaccessible-websites/feed/ 0     Google Wave Screen Reader Accessibility http://tink.co.uk/2009/10/google-wave-screen-reader-accessibility/ http://tink.co.uk/2009/10/google-wave-screen-reader-accessibility/#comments Sat, 24 Oct 2009 19:11:46 +0000 Léonie Watson http://tink.co.uk/?p=124 Google Wave is the latest innovation in online communication. It’s caused a great deal of interest across the industry, and may well herald a new era in online social interaction. It’s new, it’s cutting edge and it’s exciting. It’s also a catastrophic accessibility failure for screen reader users.

    As Jared Smith rightly points out, Google Wave is still in early preview release. It’s still in development, with many sections still shown as “under construction”. That said, the complete lack of accessibility features does not bode well for the future.

    For a screen reader user, the application is impossible to use. The principle navigation links cannot be accessed. They appear as plain text on the page, and no amount of simulating mouse clicks with the screen reader does the trick.

    There is no apparent structure to the page. No headings, lists or other useful markup to help make sense of the information. Actually, there is one heading. It’s part of the noscript alternative for people without JavaScript enabled, but I’m not sure that counts in the scheme of things.

    Visually, I’m told there are a number of panes on the screen. Semantically speaking, that information isn’t available to a screen reader user. Other information is also unavailable. For example it doesn’t seem possible to see people in the contacts pane, identify messages or read the content of an individual message.

    In short, it isn’t possible to engage with Google Wave in a meaningful way if you’re a screen reader user. The puzzling thing is why it’s like this at all.

    On their website, Google present 10 principles that contribute to a good user experience. Principle 6 includes the following commitment to accessibility:

    Google is also committed to improving the accessibility of its products. Our desire for simple and inclusive products, and Google’s mission to make the world’s information universally accessible, demand products that support assistive technologies and provide a useful and enjoyable experience for everyone, including those with physical and cognitive limitations.

    So there it is in black and white. A clear statement about Google’s approach to accessibility. Surely we can rest easy knowing that when it comes to full release, Google Wave will have assistive technology support and offer everyone a useful and enjoyable user experience?

    The trouble is that the evidence isn’t there to back this up. Google Chrome, Google Docs and many other Google applications fail abysmally to honour this commitment. With web standards, and emerging technologies such as ARIA, it really doesn’t have to be this way though.

    Perhaps the preview of Google Wave has brought Google’s commitment to accessibility into question again. Certainly a petition urging Google to become leaders in accessible website development is gaining support, and hopefully somewhere, Google are listening.

    ]]>     http://tink.co.uk/2009/10/google-wave-screen-reader-accessibility/feed/ 1