Latest Accessibility News on Accessify

Blogger Problem - Can You Help?

Since changing over this site from an ASP-driven one to PHP, I’ve had a small
problem with the way Blogger generates ‘post pages’ (that is, single pages
related to an individual post). All of the new posts on the site (since the
page template was changed) are being correctly
generated with an extension of .php
, but older
posts are being generated with .asp extensions
. There is no setting/field
in Blogger that lets you set the file extension - it seems to derive it from
whatever you specify for the main blog index page’s URL.

So, can
anyone tell me
how I get Blogger to re-publish these older posts with
the correct extensions? The .asp pages are working, but only because I’ve forced
the server to treat them as valid PHP files (not exactly ideal!)


Update: It turns out that I had to edit all the existing post (even by adding a space or carriage return) and republish them for Blogger to apply the correct extension (thanks Patrick!). Hardly ideal when you’re dealing with hundreds of posts, but at least that one’s solved!

Filed under: Accessibility
Comments Off Posted by Ian on Monday, October 31, 2005

All new Accessify

If you can see this message it means that the DNS change-over has done its thing and you’re looking at the all new build of Accessify. Everything you need to know about the re-working can be found here - What’s New with Accessify.

Please, please do let me know any issues you encounter with the new site - using the bug reporting form rather than email.

Finally, now that the site is in a fit enough for me to be able to update it easily (the problems with the previous site are in the what’s new page), I’m keen to get new articles and tutorials up here regularly, so if you have something that you think would be useful, please do get in touch.

Known Issues

Here are the issues I’ve spotted (or have been told about) that I will be looking into as soon as I can:

  • Links shifting left in Firefox: I can’t reproduce it, nor can I see why it’s happening, but this has been reported in Firefox 1.06 on the Mac. Here’s what it looks like. I could do with some help on this one, as I can’t fix it if I can’t reproduce it - and I am using Firefox on the Mac (Tiger), just the same as the person who reported the fault :-(
  • Error page not behaving: My .htaccess file is misbehaving on the live server (but fine on dev). So, the 404 page is not being served up correctly, nor are the mod_rewrite statements working properly. If anyone can explain why it’s fine on one server but not on another, please do make a suggestion
  • Features pages - indexes broken: I have spotted that if you try to view features of one specific type (e.g. tutorials only, it does not display a list. I’ll be fixing this as soon as I can (seems to be fine on development area, but not on live, so it’s probably soething simple like a case sensitivity issue on the server that I need to put right.
  • Cache problem: If you are still getting that annoying splash page (a simple list of links that was only ever there for PDAs really but I couldn’t get rid of because of various tedious reasons), please try either force-refreshing or try clearing your cache. Thanks!
Filed under: Accessibility
Comments (2) Posted by Ian on Friday, October 28, 2005

Simply Accessible

Derek Featherstone has started up Simply Accessible, a new site demonstrating methods for increasing website accessibility without compromising aesthetics or usability. Derek cites cases where a web site or component might be technically accessible, but unusable to one or more groups of persons with disabilities, and explains how to address each issue.

Simply Accessible is currently based on Derek’s presentation at Web Essentials 05 (Designing for Accessibility: Beyond the Basics). Specific examples include suggested improvements for required form fields, form error messages, search form layout, and search results layout. All are well worth a look, and we are told more examples are forthcoming.

Filed under: Accessibility
Comments Off Posted by Accessify on Tuesday, October 25, 2005

Accessify Weirdness Ahead

I’m beginning the process of changing over Accessify to new host, new design and build. Until then, there will be no postings on this page (it’s on hold) and there may be a short downtime while the changeover occurs.

Back soon!

Filed under: Accessibility
Comments (1) Posted by Ian on Wednesday, October 19, 2005

World Usability Day + Accessibility Channel / 3 November 2005

November 3, 2005 is World Usability Day (WUD), an event that will spread the word about making products and services easier to use.

Part of WUD will be the Accessibility Channel - an exciting, 24-hour global conversation about accessibility and usability.

Dozens of experts will be sharing their work with you on technology, policy, and consumer involvement. And you can participate right from your desktop. Before the event you can discuss the topics in a blog for each presentation. After the event the dialog will continue.

Register for free and tune in on November 3!

Hat tip to Jim Tobias for passing this information on.

Filed under: Accessibility
Comments (1) Posted by Patrick H. Lauke on Wednesday, October 19, 2005

Piss-Poor Publishing - (Or “Teaching New Dogs Old Tricks”)

Web design books

Just for the heck of it, and just because I couldn’t find the books that I was after in my local branch of Waterstones, I had a leaf through some of their other books on Web Design. Now, I knew I couldn’t expect great things, and I was sure that none of them could even hold a candle to Bulletproof Web Design (which I’d bought just one day previously and was carrying with me to read while waiting around for Manda to try on half the contents of the various women’s clothes shops); actually, holding a candle to any book is a bad thing to do (unless it’s a Jeffrey Archer novel, perhaps). So, I picked up Creating Web Pages for Dummies …

Oh. My. God.

Like I said, I had an idea that web design books out there were probably quite bad, but I’d never had the inclination to buy one of them, and consequently had never really flicked through. With the “Dummies” book, I flicked through and on almost every page that I settled upon I saw bad examples of presentational markup, general bad advice and supposed ‘tips’ for best practice that went out with the stone age (if not before). I found one section that was so bad I felt compelled to take a picture with my cameraphone so that I could transcribe the words here (emphasis added is mine). It read:

Believe it or not, this whole ‘tables for layout’ thing was a bit controversial at first Why? Because there were some idealistic objectives behind the original design of HTML, with it having web pages be able to display on just about any screen. Table-based layouts, by contrast, only work well on screens of at least a certain minimum size, such as a PC screen rather than, say, a mobile phone screen. The controversy has now largely faded because the people who pay for web site development demand that their sites look good on most of the PCs and Macs out there, and tables are just about the only way to create a complex design that looks good.

!

And again, !!

I picked up another book, Web Page Design in Easy Steps. It was written by a guy based in Austin, Texas, home of one of the best Interactive conferences in the world whereby each year the cream of the web design crop descend and from it wonderful things usually happen (either that or they just get sloshed). Evidently this author has never met any of these people and is blissfully unaware that things have changed since the year 2000 (or even before that). Once more I found myself flicking through a book that would appear to the uninitiated wannabe web designer to be a well presented, nicely illustrated book that would teach them what they need to know. I, however, found myself mumbling the words “No, no, no!” to myself as sin was heaped upon sin on the pages in front of me. The advice given was, once again, of the type that would only require extensive fixing later.

Who in these shops decides what goes on the shelves? Can a librarian really be expected to know everything? No, of course not. And how could a buyer (and by that I mean the person buying in stock for the shop to sell) be sure that one book is better than another in terms of the advice given? Perhaps the main factors for sellability are presentation (does it look pretty?), the cost of the book (an obvious one) or how pushy the publisher is (or maybe it’s more a case of how much money is being exchanged in brown envelopes for featuring ‘their’ books on the shelves)? I have to say that I don’t know - I am not part of the publishing business, so it’s only guesswork on my part. What I can say without a shadow of a doubt is that it’s no wonder that so many people out there build crappy web sites. And the thing is, they’ll keep on building crappy web sites until they get that Eureka! moment and switch to buying books like those linked to above, whereby us standards bods try to convert those who have been led down the path of presentational tag soup.

So, maybe my advice about holding a candle to a book being a bad idea was itself a bad piece of advice? Maybe that’s precisely what we need to do? Perhaps we should march into these shops and set up a little ‘camp fire’, Fahrenheit 451-style, to remove these heinous blots on the web publishing horizon?! Just don’t say that I sent you …

(Note: I’ve deliberately not linked to these bad, bad books)

Filed under: Accessibility
Comments (19) Posted by Ian on Monday, October 10, 2005

Interview with Matt May

I will posting up new articles and interviews directly on to the home page until I put the redesigned and rebuilt Accessify (coming soon), so apologies if this is the world’s longest post - but I think you’ll agree it’s an interesting read from a very knowledgable guy, a certain Matt May. Enjoy.

Matt, you’re probably best known for your work with the W3C’s Web Accessibility Initiative - how long did you actually work there,
and what achievements are you most happy with in that time?

I was with W3C/WAI for just over three years, from June 2002 through
June 2005. During that time, I’d say that I’m proudest of the
progress being made on the Authoring Tool Accessibility Guidelines
2.0
, which should be released alongside WCAG 2.0, and being able to
talk not just to the design community about accessibility, but also
to software developers, XML geeks, policymakers, publishers and
librarians. This isn’t just about paying someone to run an evaluation
tool over the site you launched six months ago. Everyone has a role
to play, at every phase of development.

What is (or are) the biggest frustration(s) working for an
organisation as widely distributed as W3C?

W3C operates on consensus. Consensus is about communication and
trust. And both of those take lots of time. At my peak, I was on 16
hours of conference calls a week. I had some days that started with a
call at 5am and ended with a call at 7pm. Somewhere in those other
24-44 hours a week, you have to handle meeting minutes, mailing
lists, face-to-face plans, speaking engagements, inter-group
coordination, and oh, by the way, be an international subject matter
expert in your field. How my former colleagues can do it, I’ll never
know. I think they all secretly have assistants.

What made you decide to leave? And have you actually broken ties
completely?

It was a decision I hated having to make, but ultimately I never
doubted it was the right one. The skills necessary to coordinate and
seek consensus are not the same as those necessary to lead. There are
loads of people far more organized than I am, who would excel at
coordinating a roomful of smart people to finish the work at hand.
But that’s not my skill set. I’m a technologist, and a kinesthetic
learner. I’m most dangerous when I have an arsenal of tools at my
disposal, and a hard problem that needs to be solved - which is what
got me into accessibility in the first place. Knowing that, I felt I
could more successfully advance and evangelize Web accessibility and
modern design as a practicioner.

At this point, I am back to being an Invited Expert in the WCAG
Working Group, which I’ve been in since 2000, and also in the
Authoring Tools WG.

When do you think that WCAG 2.0 will move to final, agreed-upon
recommendation status?

I think we’ll know at the end of the year. If it’s a Last Call
Working Draft, I think you’ll see a final Recommendation by mid-2006.
We’re meeting face-to-face here in Seattle in October, so hopefully
we’ll come out of that with a timeline we can hang our proverbial hat
on.

What are the best bits that the accessibility evangelists can get
excited about in WCAG 2.0?

Much of WCAG 1.0 is anchored to HTML as the dominant technology, and
expects textual documents as the delivery method. It’s too spread
out, as well, with 14 guidelines and 68 checkpoints. WCAG 2.0 is more
technology-agnostic and wide-ranging, but with a more compact set of
guidelines. The Working Group wants to put everything they know out
there so that authors can understand how a problem impacts users with
different disabilities, what part of the process is failing the user,
how the problem can be fixed sufficiently in a number of
technologies, and why we took the approach that we did. It’s a lot
different from the “do this, don’t do that” mode of accessibility we
see in laws such as Section 508. But it will ultimately answer a lot
of the whys individual developers may have been afraid to ask. That’s
good, because it lets them experiment, and improve on that knowledge.
It also boils the guidelines down into four driving principles, and
explains in detail how to meet those needs using various Web
technologies. And that’s important in itself, because it removes the
excuse that accessibility is some kind of black magic that is
incomprehensible to the outsider. Every guideline exists for a
reason, and all those reasons are now spelled out.

And on the flip-side, what parts of WCAG2.0 don’t, in your
opinion, really hit the mark for whatever reason?

There are three priority levels in WCAG 2, just like in WCAG 1. And
like WCAG 1, some people want there to be three conformance levels,
too. I think that’s the wrong approach. If you look at sites that
claim to conform to WCAG 1 at Triple-A level, which means they
covered all 68 checkpoints, you’ll see without fail that they
haven’t. For a site of any complexity, Triple-A is simply not
achievable. There are even cases in there where doing one checkpoint
to satisfy the needs of one disability group will harm the
accessibility of another.

Now, the value of marks like these is in the confidence among users
that they mean something. If you put out a mark knowing that nobody
is going to actually reach it, and people start to distrust the mark
as a result, you’re hurting the cause of accessibility overall.

I’ve lobbied for a long time to have only two levels of conformance:
Single-A, where you meet all Priority 1 criteria, and Double-A, where
you meet all Priority 1 and 2 criteria. If you want to say that your
content meets this or that Priority 3 criterion, you may do so in
metadata, so that users know what to expect. Those who want three
conformance levels say this would make Priority 3 items optional. But
I would much rather see people do what they know they can achieve
than claim, through ignorance or just plain lying, that they’ve done
things they really haven’t. The conformance mark is about service,
not status.

My other concern is with how the document will be received, though I
don’t think it can be solved (or is meant to be solved) by the WG
itself. WCAG 2 sacrifices some of its usability for completeness. A
lot of people are going to be disappointed if they expect WCAG 2 to
be introductory or educational in nature. Some would say that’s
necessary: specifications are meant to be as unambiguous as possible,
which means precision is more important than prose.

I’ve wanted to be as informative as possible in the document and its
ancillary materials, but that’s not a substitute for a higher-level
explanation of the document. As a result, all the information will be
there in excruciating detail, but you won’t be able to hand the final
spec to a novice developer and say, here, now get to work. Further,
the WG isn’t chartered to attempt this explication itself. There will
need to be tutorials and methodologies and courses and books built
around it before it gains traction in the real world. But, by the
same token, I doubt very many people learned JavaScript or C# by
reading the ECMA specifications. Specs don’t mean much to the end
user without context and interpretation.

You’ve just started a new company with a whole bunch of other
great people. Tell us about that - how it came about, what your
short term aims are

The company is called Blue
Flavor
, and it’s made up of four people who got together because
they wanted a challenge. Or, more to the point, a whole lot of them.
We have a combined 42 years of professional Web development between
us, and we’ve each grown organically into complementary roles: Keith
Robinson is a creative powerhouse; Nick Finck is a top-notch
information architect; Brian Fling is a mobile hotshot and a
brilliant strategist. I like to make stuff that works. Together, we
are driven by the user experience, and we insist on working with
clients that feel the same way. Those who don’t, we’ve turned away.
Life’s too short, you know?

Are you just going to be ‘the accessibility guy’ at Blue Flavor,
or will you be given chances to flex other creative muscles?

My title is Director of Technology. I’ll be determining how we
implement the sites we design, prototyping them, doing a lot of the
coding for them, and reviewing them for a number of factors,
including accessibility. I made it a point to step back from being
The Accessibility Guy so that I could see the big picture, and work
on ways to integrate things like Ajax, Flash and voice over IP -
where appropriate - into a better experience for everyone. I’m
staking my reputation on proving over and over that accessible design
can be just as beautiful and elegant as the inaccessible alternatives.

Back to accessibility again, what do you feel presents the
biggest challenges to web accessibility in the near future?

Two things. First, the cost and capabilities of assistive technology.
Recently, there’s been lots of talk about the advanced capabilities
of modern screen readers, for example. Many of the accessibility
techniques we evangelize are broken, it turns out, in older screen
readers like JAWS 4. Until we can establish that the Web is really a
better place when you use these updated tools, content creators are
going to receive conflicting signals as to the accessibility of their
sites. It’s analogous to that userbase of Netscape 4 users we spent
so long adjusting to when we weren’t wishing them away: is it our
responsibility to adjust to their broken user agent, or is it their
responsibility to stay up to date?

Socioeconomic factors come into play here: unlike upgrading your
browser, for free, to take advantage of new features, it could cost
$200 to $1000 to upgrade an old screen reader. We want users to avail
themselves of the most capable tools for the job, but they may not be
able to afford them. This is why I have high hopes and expectations
for VoiceOver on OS X and Gnopernicus on Linux and Solaris. They’re
lowering the cost barriers for accessible computing to effectively
zero, and both projects are tackling the hard interface issues in
modern development, such as how to represent dynamic changes to the
DOM in a logical way to the user of a braille display.

Number two: what is absolutely killing me these days is that as
“accessibility features” are being used more and more by people who
don’t identify as having a disability, even more are so hidden from
the average user as to be ghettoized. If you’ve used Find As You Type
in the Mozilla Application Suite, you’re using an accessibility
feature. But there are all these others buried in the tools and
operating systems we use every day: font and color selection and
override, user style sheets (and now user scripts, with
GreaseMonkey), keyboard shortcuts, magnification, monochrome and
reverse displays, text-to-speech. I use several of these regularly,
despite not having any perceptual disability. Why hide these features
when they could help so many? We should have an Accessibility Hacks
book just to show it all off.

You’re heading up the WaSP Accessibility Task Force - can you
tell us what’s happening with that, plans for the next 6 months,
for example?

I’m excited about what we have assembled here. We have a roster of
very talented people who care about accessibility and technology, and
that, in my opinion, is just what we need to be of service to today’s
designers.

We’re going to start with a blog, to get the conversation started. I
think we’ll be asking as many questions as we’re answering during
that time. If the WCAG WG needs help fleshing out 2.0, we’re there
for them. The same goes for browser and authoring tool vendors. I’d
like to take some real problems and show how they can be fixed
without compromising on a given design. We can take a page from
WaSP’s own playbook here by taking a known-inaccessible interface out
in the wild and showing how it can be done accessibly. It’s not like
we’d have to look very hard.

Playing devil’s advocate, does the world need another
accessibility group and what makes WaSP different from others with
similar aims?

Accessibility has a long history of being at the leading edge of
technology. We’ve seen that waiting for things to settle before
making them accessible is not a successful strategy. With all of the
Web 2.0 technologies flowing, and new architectures and interfaces to
richer data springing up literally every day, we need a group of
people who can blaze a trail. I want for us to provide the
unvarnished truth about Web accessibility: what we can fix, what we
can’t, what we need. We don’t want to “certify” people or sites, or
present a competing standard, or sell executive reports. We just want
to share what we know, learn what we don’t, and push the state of the
art of accessibility forward.

Let’s end on some positives. Firstly, what sites or work have you
seen recently that’s made you say wow once you’ve realised that
it’s accessible

A couple years ago, I was looking for a photo site to post lots of my
stuff: wedding pics, travel shots, you name it. I found Smugmug. Aside from its feature
set, the thing that sold me was that it was built accessibly. Not
only can you apply alt text to every image, but it will carry over to
the thumbnails, and they’ll add context in the form of the gallery
title when you’re at the top level. If you wanted, you could search
for a picture of Matt May eating sushi on the Shinkansen, and buy a
print of it, even if you can’t see it yourself.

Why would a blind person order a picture? More people lose their
vision during their lifetimes than are born without it. All of them
have sighted friends and family. (I know two people who are totally
blind and carry cameras with them to share their experiences with
others: one uses an SLR, and one has a camera phone running a speech-
enabled interface.) If they want to buy a photo as a gift for a
friend, who are you to stop them? Instead of asking why they should
care or who would want to do such a thing, and with very little
effort and no fanfare, these developers just enabled it. If a photo
site can enable the experience for blind users, why can’t everyone else?

Secondly, do have any tales of how what you’ve worked on in WAI
mode has had a direct impact on the way someone you know or have
heard from that’s made you think “That’s why we do this”

I think the most direct feedback I got was from the paper I wrote on CAPTCHAs. CAPTCHA is a technology that is
literally inaccessible by design, and the contortions and
perturbations many CAPTCHAs have implemented have made it almost
impossible for perfectly sighted people to use. I suggested that
making Web resources inaccessible is not the way to stop spammers.
It’s a stopgap method at best, and we’ve already found numerous ways
to exploit them, both programmatically and through cheap labor.

Since that time, many of the major users of CAPTCHAs have moved in
other directions, including things like logic puzzles, heuristics and
limited-use accounts which I outlined in the paper. Even the
developers of CAPTCHA engines have shown themselves to be sympathetic
to users with disabilities, and are working on more inclusive tests.
I’ve also had tons of people explain that they now realize CAPTCHA is
not the solution to all the world’s ills, and they’ve gone back and
thought about what it is that they’re trying to guard against. I like
it when people think. They tend to come up with solutions.

Filed under: Accessibility
Comments Off Posted by Ian on Friday, October 7, 2005