Hiding or Disabling

I recently reviewed a web-based file manager for accessibility. It was laid out as a table, with information about each folder or file inside its own row. Each item could be opened by clicking it’s name, or selected via a checkbox, for further manipulation.

Above the table was a set of action buttons such as “Move”, “Rename”, “Delete”, etc. These buttons would appear when one or more items in the table were checked, and disappear when no items were checked.

This worked well for folks who could see, but posed a problem for screen reader users. How would a blind user know that the action buttons had appeared? We could have added an ARIA alert, but that probably would have been more confusing than helpful, and wouldn’t have help screen reader users know where to find the action buttons.

The solution we ultimately adopted was to not hide the action buttons at all–at least not for screen reader users. Instead, we made the buttons hidden for everyone except screen reader users, and marked them as disabled. That way, since they came before the table, screen reader users would see them, and they would hopefully deduce that if they wanted to perform any of those actions, they could do so after selecting the files or folders.

The takeaway from all this, in my view, is that when causing new controls to appear on screen, that are far from where the screen reader user is currently “looking”, can require some careful consideration to ensure that the user knows that they have appeared, and where to find them. I am not aware of any clear solution to this problem, and I believe that it is best avoided if at all possible.

Accessibility Bookmarklet for StackOverflow.com and Friends

Update: This issue has now been fixed, making this hack unnecessary.

Recently, the developers behind StackOverflow.com changed their site in such a way as to make voting and flagging inaccessible. So, I created a bookmarklet to correct the issue, and these functions now seem to work fine for me with a screen reader. Note that this will likely not work for older screen readers that don’t speak ARIA.

Of course the best solution would be for the StackOverflow devs to make these changes to their site directly, but until that happens, we will have to make do.

It’s amazing what just a little bit of ARIA can do.

javascript:(function(){$(‘a, .vote-up-off, .vote-down-off, .star-off’).attr({role:’link’,tabindex:’0′});})()

Simply right click the above, and save it as a bookmark. Then, when you visit the StackOverflow site, or any of their sister sites, click the bookmark, and the page will magically become accessible.

The biggest drawback to this is that you have to run the bookmarklet each time you visit a different page on the site. So, if you visit the site frequently, I suggest you install the script into Greasemonkey, and set it to run on all pages of the site.

Feedback/improvements are appreciated.

Use ARIA to Indicate When Form Fields Are Required

The next time you create an HTML form with required fields, consider adding the aria-required=”true” attribute to the required control.

<input type=... aria-required="true" .../>

From the ARIA draft:

Indicates that user input is required on the element before a form may be submitted.

For example, if a user needs to fill in an address field, the author will need to set the field’s aria-required attribute to true.

Note: The fact that the element is required is often presented visually (such as a sign or symbol after the widget).
Using the aria-required attribute allows the author to explicitly convey to assistive technologies that an element is required.

Unless an exactly equivalent native attribute is available, host languages SHOULD allow authors to use the aria-required attribute on host language form elements that require input or selection by the user.

This property is supported in just about all screen reader/ browser combinations that support ARIA. However, for backward compatibility, you should still include some sort of notice in the controls label. An asterisk seems to be the most common, and most users know what it means.

When a modern screen reader encounters a control with the aria-required property set to true, it will simply say “required” in addition to announcing the control type. For example, jaws will say “required edit” when it encounters a required text entry field.

As with every accessibility feature, be careful not to over use this. A good rule of thumb is if you visually indicate that a field is required, indicate the same with ARIA. Likewise, if you don’t visually indicate that a field is required, then don’t do so with ARIA either.

When a Site Just Isn’t Accessible.

When I come across a web site that isn’t accessible, I usually just leave. However, if I really want to access that site, I can often do so through the mobile interface, assuming it is available.

This work around isn’t perfect, as the mobile site almost never has all the content or features of the main site. However, limited access is better than no access at all.

The other, more serious problem I encounter when using this hack is caused by some sites that recognize that I’m using a browser on a PC. It is possible to fool the server, but it’s not easy.

The fact that this work around exists is of course no excuse for not making your main site accessible. However, if your main site is inaccessible, and you have a mobile version of your site, at the very least, don’t block it from being able to be viewed in Firefox or IE.

Remember also that a mobile site is no substitute for making your main site accessible, unless it simply isn’t feasible, you provide as much content and functionality as possible on the mobile site, and you place a prominant link directing users with accessibility needs to the alternate site.

Finally, just because a site works on a mobile device doesn’t mean that it is accessible, though the odds are much greater that it will be. Nevertheless, the standard web accessibility advice and guidelines still apply.

Requiring Right-Click Can Make Your Site Inaccessible

It’s not uncommon to see the instruction, “To download the file, right click and …”, but this can be difficult or impossible for screen reader users to do. The problem is that Jaws and Window Eyes don’t offer an easy way to right click on a link. I can do it, but it’s sometimes quite difficult, even for me, a reasonably advanced user.

If the link is text, I have to use the Jaws cursor to find the link on the screen before I can right click it. (The Jaws cursor is basically the mouse, but you move it with the arrow keys and click with the keyboard.) Just finding the link can often be a slow process.

However, if the link is an image (<a href=…><img src=…/></a>), there is no text for me to find with the Jaws cursor. The only option left to me at that point is to click on the link, quickly press ESC to cancel the page loading, and then press Shift+F10 to right click on the link. It took a lot of trial and error to come up with that procedure, so it’s a pretty safe bet that most users won’t be able to download content from these types of links.

This is a major oversight that needs to be addressed by the screen reader manufacturers as soon as possible. But in the meantime, you should avoid requiring your users to right click. If you want to offer content for download, you can either zip the file, or change the content-type sent to the browser. Zipping the content is probably the easiest option, as most web servers will automatically serve such files with a content-type which will cause browsers to prompt the user to save. Changing the mime-type sent to the browser is only slightly more difficult, and can be done with a little PHP or the server-side language of your choice. Unfortunately, I don’t know of any way to accomplish this with JavaScript, but if you do, please post in the comments.