] >
I will not, unfortunately, have the opportunity to attend the upcoming Edge of the Web 2011 conference, despite the fact that I'd really like to, and despite the fact that it looks to be an excellent event, and despite the fact that it's in my own home town. It is indeed rare that quality events are hosted in Perth. If anyone was looking forward to meeting me there, I apologise.
What I thought that I'd do instead, since it is an event with a significant focus on web accessibility, is take a look at the EotW 2011 website itself, and give it a quick analysis from an accessibility point-of-view. This is not intended to be a full report; just something to give everyone some ideas.
I'd like to note that although I am not currently an Australian Web Industry Association member, I do not have a bad relationship with AWIA; they're an important and useful association that represents the web industry in Australia, and our interests coincide greatly. This article is, quite emphatically, neither a complaint, nor an attempt to embarrass.
Update: Like most of the web, things are updated all the time. Since the original article was written, AWIA have finished updating their website, and their online membership signup now works - although, this was not until after the end of the Edge of the Web 2011 conference.One more thing that I'd like to make clear first; if my analysis seems overly-critical, please consider that, compared with the vast majority of the modern web, this website is very accessible. I'm only pointing out that being to some degree accessible, and being compliant with accessibility standards, are different things entirely; and that there's always the opportunity for continuous improvement.
Okay, let's begin!
Mostly, this is excellent. Contrast is maintained well enough for all but the poorest vision, and the layout is clear. The text is a bit small, and the content doesn't flow well when the text is zoomed, but it's still readable except for the inconvenience of scroll bars (which, admittedly, are quite a critical inconvenience for some users).
The only important flaw is that the main heading cannot be seen when CSS is rendered but images are not.
Most of the important information here is text, and mostly, there's nothing special that has to be done to it to make it accessible. However, practically none of the abbreviations and technical or slang terminology get explanations – likely due to the intended audience. Overall, it's still very good.
Unfortunately, there are out-of-order headings, but that's the only failing; it is otherwise excellent.
Actually, there is a glaring exception; there's a frame (bad enough by itself), and the markup within it is atrocious, including such delights as layout tables and EcmaScript links. It's a very well-known offender, and I'm going to be generous and ignore it for this analysis – going on about this again, here and now, is futile. There are things that web developers can do about it, but I'll explore those in another article.
Things get a bit worse here. It was a good site when all you had to do was read from it; but can you navigate through it?
Mostly, it works well. The main navigation links clearly state their destinations, and are a reasonable way of sectioning the content.
The inline links are almost as good; although there are a handful that aren't very meaningful out-of-context, and most of the in-page links refer to the same sections that they are included in, making them useless or misleading. A couple of links depend upon EcmaScript; thankfully, none of the main navigation links – but there's still some content that you can't get if you're using a graphical browser that supports CSS but not EcmaScript (there are more than you think!).
There's no easy way to skip the navigation block in most browsers, and in others, the tabindex values make getting to any particular link aggravating and unnecessarily difficult.
There is no search functionality, although it's probably a small enough site that it doesn't really need it; the sitemap is effective enough.
Unfortunately, there are also problems here. Reading the site and navigating it have been dealt with; but can the site be used to complete the task it was built for?
Probably the single most important function of this website – in fact, the main reason that it exists at all – is the signup for the conference. To start with, there's the opportunity for a discount, if you become an AWIA member.
Does that sound good? Well, that's too bad. The signup page doesn't work:
Apparently it'll be working again as soon as possible
. There's an email address (in raw text, i.e. not marked-up as an email address) in that error message which you can contact for urgent questions or problems
, but no indication of how long it might take, or whether that might be something that they would agree is urgent (when most web users are faced with such an error, they're either fixed in seconds or hours, or else they never get fixed at all). And, there's no alternate method of contact, such as a phone number (in fact, there's no phone number or general contact email address anywhere on the whole AWIA website).
(Just an aside about the phone number: there's a good reason that a phone number is not provided on the website in general, and that is because AWIA does not operate a phone line strictly for enquiries. The idea is that, as an association specifically by and for web industry professionals, phone lines and full-time staff to answer them would just be wasteful of their member's funds when virtually every enquiry could be handled electronically for almost no cost. This is a perfectly reasonable position, but it makes some kinds of contact a pretty significant effort under these kinds of circumstances. A generic contact email address would be very useful, however.)
The signup page has actually been offline for a very long time; however, they do have an alternate downloadable AWIA Membership Form… but it's a PDF. And it does have a tagged stream… but it's comprised of nested tables and out-of-order sections. It's basically unreadable, if you can't read it once you've printed it out onto a piece of paper. And even if you managed to read it on a computer, you couldn't complete it on a computer, because there are no form fields. And even if you were to edit the form directly, there's no email address – either on the website, or written on the form – to return it to; it has to be posted.
Doesn't this conference have a talk by Gian Wild, one of Australia's foremost accessibility experts, on what – if anything – can be done to make PDF files accessible?
Okay, so we'll forget about membership and the discount. Let's sign up for the conference.
The signup for the conference itself actually redirects to another website, too. This is not uncommon, and is not a problem in itself. But how accessible is the other website?
Depending on how you're viewing the website, the first thing you may see after following the signup link is a warning that the Location URL is not absolute
. Basically every browser now handles this case and will correctly do what the server operator meant, but it's still disconcerting.
Once again, I'd like to add a disclaimer: this website is in general very good, and is certainly far better than most of the rest of the web. This is instructive (or at least demonstrative) criticism only; not victimisation.
This website is quite logically presented, and very clear at first glance.
It is designed to use a more-or-less fixed layout, and doesn't handle zooming, scaling, or uncommon window sizes, very well. It is manageable, however, and doesn't become unusable if you are using unanticipated settings.
Forms are always difficult to make accessible, and this form is pretty good; but there's always room for improvement, and just a little bit of accessibility testing would have revealed where. Consider how the first part of the form would read to a person using a screen reader (try reading it aloud):
DETAILS
SLASH
INFO
PERSONAL
STAR
EMAIL
COLON
It sounds like gibberish. If you used a screen reader every day, you'd get quite used to forms being read that way. And everyone who has filled out enough online forms, knows that an asterisk indicates a required field. But what about people who don't do one or both of those? If you're going to use an asterisk in that way, you must explain what it means – and preferably at the beginning of the form, so that users dependant on screen readers don't have to listen to a page full of nonsense to work it out. A better solution would be to use a graphic of an asterisk, have the word "required" as alternate text, and then you can explain at the (visual) bottom of the form what the asterisk means. While you're at it, move the asterisk to the other side of the field name, and remove the colon; and in the heading, remove one of the redundant words and the slash separator. You would then have:
DETAILS
PERSONAL
EMAIL
REQUIRED
Interestingly, there are some, mostly but not entirely, harmless, anomalies with the form. Why is a twitter name required? What if you don't have one? It's actually not required; it's just marked as though it is. What about the Organisation/Company? Firstly, do they want a trading name, or a registered name, or an ACN or ABN? And what if you don't have one? Actually, that's not required, either.
And the Click to Show/Hide this box
icon? That requires EcmaScript, so it would have made more sense to insert them using EcmaScript on the page load, so that they aren't there if there is no scripting support; otherwise, they just add clutter and have the potential to confuse.
On the Finalise (payment) page, if you elect to use a credit card, there is a notice – ** DO NOT enter spaces**
– using ASCII-art for emphasis instead of <strong> markup; I've already said how difficult it is for screen reader users to understand this method of marking text. Also, it's probably better that you use server-side scripting to remove spaces, but if you can't, it is indeed better to let the user know. Although, you should let them know before they start typing; place the warning near the top, or at least before the credit card number input box.
Other than these quirks, though, the signup is mostly straight-forward, and mercifully completable even with a terminal browser that lacks image and scripting support; that's rare enough to get bonus points. Despite a lack of awareness of how accessibility affects how people use their browser, this is actually one of the most usable and compatible forms I've seen – well done.
As far as I could tell, there was no offline method of signing up for this conference (certainly no forms or contact details on the EotW 2011 site), but don't quote me on that, because I didn't have time to find out for certain. If there was, it wasn't obvious, however.
Although in some, mostly immediately practical, respects, this is less important to users, it is still an area that is important for accessibility because problems of this sort discourage advancement in accessible technologies.
The markup doesn't validate, and neither do the stylesheets.
The markup, in this case, is XHTML 1.0 Strict. Why would you use that document type, when you use none of the three or four minor differences between it, and XHTML 1.1? It's been over ten years, guys! You can't possibly have any good reason (especially since the site doesn't validate anyhow)!
Why isn't the language specified?
For most users, these kinds of problems are the most minor, with the browsers that they use today. But they reflect very poorly on the developers (or at least operators) of the site, and they won't just break on the user agents of tomorrow; they make the user agents of tomorrow take that much longer to even exist. Not all of the user agents of tomorrow will be browsers; they'll be human language translators, and vehicle user interfaces, and government licensing assessors, and more; just as they've started to become bank tellers, and airline booking systems, and home entertainment system user interfaces, and other things not even imagined two decades ago. They promise incredible possibilities for accessibility, but none of it will ever happen until developers start getting this sort of thing right.
While this is a great site at first glance, and still better than most when you use it, it really could have used a bit more testing – or better, peer review – before the project was signed off as complete.
Also, if you're running an event, or even organisation, of any size, even if it is extremely modern and intended mostly for people who are very experienced with using the web for almost everything, you could still do with an offline alternative. It doesn't have to be difficult or expensive, and it's a simple kind of insurance against technical problems or the occasional user with special needs.
Have a great time, everyone!