Too much accessibility

Good intentions, badly implemented

HTML offers many features and attributes that can make your sites more accessible...but only if they're used wisely. Can there really be "too much accessibility"?

Transcript

Dan Champion: Patrick is responsible for the web at Salford University. He's also joint leader of the accessibility taskforce for the Web Standards Project. And does some freelance work as well, I believe. So, Patrick is going to ask the question, "Can there be too much accessibility?"

Patrick H. Lauke: Thank you. Right, I've got about a gazillion slides. It's all very opinionated stuff, so it's not gospel. This is just my view on certain kind of topics. And honestly, I'm going to talk, and talk, and talk until Dan physically removes me from the podium.

A little anecdote...

So, we're going to start with a little anecdote really, a bit of a story time. It was about a few years ago, while I was at Salford…a few years ago, we were about to embark on a redesign of the main site. And a colleague and I decided let's go and visit this member of staff. He's a web developer. He happens to be blind and a fairly proficient JAWS user. So, we went along, and we just asked, "Are there any major issues with the current site?" Which I'd inherited at that point. And I knew it was quite shit. So, I said, "Can you go through the site with us and just show us a few of the things that we should look out for? We've got a pretty good idea what needs to be changed, but let's have a look. What are your problems?" And he kind of went through it, and we made loads of notes. A few good pointers. And he also mentioned that you can actually download the evaluation version of JAWS for free. You can run it for 40 minutes and run your sites through.

Then a few weeks later, I kind of bumped into my colleague that went along as well. And she said, "Oh, you know what? I downloaded that version of JAWS, and I ran through various sites that we run with JAWS. And isn't it terrible, you kind of get to this page, and it's so long. And it just reads, and reads, and reads. So, what I thought is how about we shorten all our pages and make them into real kind of bite-sized little pages with loads of previous and next links?" Obviously, that shouldn't be done because that's not the way screen reader users actually use screen readers. They don't get to a page and just passively sit back and kind of listen to the whole page. It's a very much interactive process. They speed things up, slow things down, jump from heading to heading, backtrack, etc.

But she didn't realize that, so she had this idea of like Ann mentioned before. It's such a tedious process, poor blind users and screen readers. We need to make something…do something on the site to make it easier for them. And this is kind of the topic of this presentation: she obviously meant well. She wanted to do it for the right reasons – to help people that are using screen readers. But she obviously completely missed the point of how they actually use screen readers and what is the right thing to actually do.

So, when you're building web pages, there are many ways to improve accessibility on your site. There's HTML attributes and elements that you can use. Specific techniques or adding certain features to pages, certain helpful kind of additions to the pages. But you really need to know when and where these should and could actually be applied.

And yeah, the common mistake really, as illustrated by my little anecdote, is it's not really understanding the user behavior. We see the technology. We see this attribute can be used for this, this element can be used for this. We don't really know a lot about - unless you've actually got a screen reader, or you've got access to people who can show you how it works with a screen reader - we're kind of working a bit in the dark, laboring away, imagining that, "Well, if I put this in, the screen reader will probably do this or will probably do that. Or I imagine that somebody who's deaf might find this useful rather than that." So, there's a lot of misunderstanding of, or not understanding of, how users actually interact with our sites.

And also, sometimes you get developers that just get the specifications. They treat it as a technical document. They see WCAG requirements, they say, "I need to so this, this, this, and this." This is kind of a checklist approach. They don't understand necessarily why it needs to be done or how doing that actually helps a real-life user. They treat it as a, "Right, that's just another checkpoint. I need to tick that off my list." And then there's people that, again, are well meaning. "I know that adding this feature is good for the site. I know that adding that feature is good for the site. If I put these two together and add both of them, that will make it accessibility plus." And that doesn't always work that way.

So, let's look at a few examples that bug me. In no particular order and I said, in my usual style I'm just going to rant away at things that really bug me. Take it or leave it. They are very contentious kind of things. I'm going to make a few assumptions. I'm going to talk about my personal preferences. As with everything with accessibility, there's no clear-cut, black or white kind of answers to things. This is just the Lauke version of what is wrong with the web.

alt text

So, alt text, as we know, it's the first checkpoint, the simplest that you would think, to provide text equivalent for all non-text elements. And it talks about in the HTML spec, for user agents that can't display images, forms, etc. This attribute specifies alternate or alternative text. So, you would think, as I said, it's an easy case. And most of us should hopefully by now know what is and isn't good alt text in certain situations. If you've got bullet points, we should know by now that it's irrelevant to actually say, "This is a bullet point," or actually describing it. "This is a blue ball," etc. You just use a normal list and style it away with CSS, add that little graphic.

Spacer graphics, again, if you're still using spacer graphics for whatever reason… Maybe your CMS doesn't allow you full CSS kind of layout. Yes, use it by all means. But please don't put "spacer" as the alt text for the image. It's bad enough that you're using images for kind of layout purposes. A screen reader user doesn't necessarily need to know that you've got 15 little 1-pixel icons here and there just to get that kind of text in the right place.

And then purely decorative images. Now, there's a lot of debate, and you'll get hard line views from some accessibilistas saying every time you put an image in, that needs alt. Because if it doesn't convey anything, why did you put it in the first place. I've got my own views about it. There are certain types of images that we add to pages purely to add a little bit of interest. But, you know, the kind of stock photography, two businessmen shaking hands. Does that really need a particular kind of long description or alt text that explains it? If it conveys a certain kind of feel, or mood, or whatever, I would assume that the equivalent to that is actually writing your copy, the rest of your copy on your page in the same style. If you're trying to portray a trustworthy organization, your copy should reflect that in the same kind of subliminal way. But it's not that easy.

So, I've just kind of mashed up my site a little bit. So, to see the extent… Because obviously when we talk about alt text, the context is important. You can't just take an image out of context and say, "What's the best alt?" So, here on the University of Salford homepage, we know hopefully by now that an alt text for the logo of "logo featuring the Salford Lion with the words 'University of Salford' forming a circle around it…" A lengthy discussion about what it looks like is actually irrelevant. Because if you really needed to explain that, you would put it in a long description. But I would argue in this case it's actually unnecessary. But another thing that you do find quite often is prefixing things like "logo of the University of Salford." Or "photo of," etc., etc. Is that necessary in this particular context? I would argue it isn't.

I would say that the best way to mark the alt for the University of Salford logo is just "University of Salford." Because somebody who can't see the image or any graphics, that is what the image is serving…the purpose that the image is serving. Just basically alerting people that this is the University of Salford website. So, unless the image is the content… And an example of that would be say a page on a graphic design blog that just compares different types of logos of organizations. And it just starts talking… Basically it shows the logos because it wants to illustrate this organization uses, I don't know, a swoosh. Whereas this organization uses little dotted lines, etc.

Then yes, it might be relevant to actually add that type of description that says what the logo actually looks like. But for 90% of the cases when you're actually just adding a logo to your site, I would argue that the name of the organization is enough, and any kind of strapline or whatever that you've got. And for that reason, it's irrelevant to say, "Oh, this is a logo of…" As well, etc. That is implicit in the fact that it's just at the top there of your site. What else could it be? Again, if you wanted to a comparison of, "Here's some photographs. Here's some illustrations." Then the fact that one is a photo, and one is an illustration, you may want to add that to your alt text. Because that, again, is content, and that is relevant. But for most cases, you don't really care, and you should just leave it out.

I see the lovely corporate templates that we've got for PowerPoints actually have a really horrid color for links. But once you get the presentations, there's a link to a good article from Mike Cherim, who also runs access sites where he talks a bit about these issues in greater detail, about what makes a good alt attribute really.

So, moving swiftly along, title attribute, along the same lines.

title attribute

WCAG says clearly identify the target of each link, and content developers may further clarify the target of a link with an informative link title. And HTML spec tells us that title is for advisory information for any particular element. So, what you still see… And there was a debate on a mailing list that I kind of joined in. I'm always ranting away at mailing lists. The other day about somebody having links and then prefixing…a similar thing to the logo issue…prefixing a link to a particular page with "link to:" and then the actual repeating the name of the link. Now, is that useful? I would argue not. Because even if you're using a screen reader or you're using even links, anything like that, the actual browser or the assistive technology already identifies that something is a link. So, you're being a little bit patronizing by saying, "Oh, you know what? This is a link. Don't worry. You can click it." Yeah, you could add, "Please click to actually navigate over. And this is what a mouse is," etc.

Now, a slightly less evil way, kind of almost turning it into a bit of a phrase – navigate to the study at Salford section where the link already says "study at Salford." Again, similar kind of thing. Is that really necessary? I would argue it's not. It can also with anything like that with pop ups, that kind of tool, tip type things that come up, it can have a…constitute a problem for people with say screen magnification. It starts kind of interfering. It pops up. It might confuse people. People with cognitive disabilities might be started by the fact that there are these things that kind of keep popping up, and all they want to do is just move over and look at the link.

And one that I think Joe Clark initially talked about and I think…search engine optimization experts will still tell you, some of them anyway, that that is a really good way of kind of improving your ranking. Especially since you've got a link text that's already quite clear. Just repeat it, again, in the title. It doesn't do any harm. It gets you more key words in your page. Again, for the same reason, it can actually distract certain types of users. It can be detrimental. And it bloats up your mark up if you've got loads of links on your page. I would say, as my personal view is, scrap it. It's not needed.

So, a quick recap. As I say, link to, navigate to, etc., is useless. Browsers and assistive technology already tell you what's the link, identify what's a link. Duplicating link text, I would say it's dubious. And I think… I don't have the data for it, but I think I've read somewhere that certain search engines are starting to get wise to that particular thing. If you just kind of duplicate things just by putting title in. And as I say, it can interfere with certain assistive technology or just it can create kind of usability problems for certain types of users – users with cognitive disabilities, for instance.

It can be used in certain situations. We've got the contradictory – every link should really be unique. And then we've got certain types of sites where say you've got loads of kind of stories, and you want just to have a link that says "more details" or "read more about it." In certain situations, yeah. I've been known to use that myself where the actual clear link text says "more details." And that in the title, you say, "More details about…" And then repeat the name of the story. Although, again, at that point you need to be aware of certain browsers might not display that title information. So, if you're using keyboard, if you're moving around via keyboard, they will not show that information. Certain screen readers, depending on the setting, they will not announce the title. But it's a bit of give and take.

Default text in forms

That's one that is slowly on the way out, but I still see it on occasional sites. Because WCAG helpfully back in 1999 told us that until user agents handle empty form controls basically…so, inputs text areas…you should really add default text in there. That dates back to, as I said, 1999. I think at the time there was a problem with one particular set up, which was I think OS9, Netscape three or four, something like that. And the screen reader from Mac, whose name escapes me at the moment. That if the input was actually empty, it would completely be ignored by the screen reader. So, that's kind of where it stemmed from at the time. But now a days, it's really not necessary anymore.

So, if you imagine a form, you've got in every single field…you've got your label. You do everything right. You mark everything up, label, input. They're all tied together. Then you think, "Okay. Well, to satisfy that WCAG checkpoint I'll just add 'enter your first name,' 'enter your last name,' etc., etc." Well, that's great, but it can actually have usability issues for people. So, not necessarily making it inaccessible, but you're just making it that little bit harder again for people. As I say, it's not an outdated technology. In 99.9% of cases nowadays you don't need it. Screen readers and browsers are quite fine. They do recognize inputs when they're empty. So, don't bother putting that stuff in. And as I said, if I'm a keyboard user and I end up on that field, the first thing I need to do is first delete whatever was in there and then retype it. Now, there's a lot of JavaScript floating about that you can kind of plug in. And if you've got default text, it will delete it for you. And then if you click back out without typing anything, it puts it back in.

That's great, but I would advise if you, for whatever reason, really want to have that text kind of appearing in there and everything else, also do it the smart way. I've written a little script. That's my personal site there. There's some little experiments I've done. It's a little script that basically in the markup there is no default text. The script first runs when the page is opened. It then puts the default text in, and then has got that functionality to remove it and make it disappear when you click in and make it reappear when you click out. So, basically if somebody comes along with a browser that hasn't got JavaScript, or JavaScript is disabled, they don't still end up having to delete stuff.

So, going about it the smart way really.

fieldset and legend

Again, WCAG tells us in very broad terms you should kind of chunk up your content effectively, putting blocks of information together. And also partly related to that is associate labels explicitly with their controls. So, if you've got something like a set of radio buttons, they're all related to each other, there's kind of one overarching question – "How do you find out about our CD rom?" And you've got your various kind of radio buttons, and they've all got their separate labels. And there's a fieldset around it. And what I've done there is to show I've got, "How did you find out about our CD rom?" That's the legend for the fieldset. So, it's all kosher. That's all the right way to mark it up and everything else. Now, in certain situations though for certain screen reader users, I think with the default settings, as they work their way through the various radio buttons, what the screen reader does is every time they hit the new radio button, it reads the legend first and then appends the label to it.

In this case, it might be very cumbersome, and it might represent more of a usability issue or an annoyance if every time I tab it says, "How did you find out about the CD rom website? How did you find out about the CD rom radio?" But there are other situations if for instance there wasn't any punctuation at the end of the question on the legend or anything like that. You might actually get very bizarre combinations as it starts kind of merging the legend and the label together. So, it's something to be aware of. Some could argue that it's a shortcoming of assistive technology. Maybe it shouldn't read it every time you tab through. But the reality at the moment is that if you're doing something like that, you should be aware, and you should kind of not completely change the way you mark or write things…mark up or write things on your pages, but you just need to be aware that the right choice of words can help in those situations.

I took the easy way out and actually avoided the whole debacle by turning that one into a drop down. So, it's just normal select and a label, so none of those issues. Obviously if I just go back on…obviously that was an easy choice to make, going from that to that. I know that certain sites try to do the right thing and start putting field tests and legends around all the sub sections and everything else. If you've got a large subsection where you've got like first name, last name, address, post code, etc., put a big fieldset around that, put a legend "personal details". And then you've got another section that has got something else. I don't know, "shipping address". Another one that says "billing address". Just be aware that the more you do that, the more screen readers will read that legend on every single kind of input. Unless the user changes their verbosity settings.

So, it's something to be aware of. I'm not necessarily saying don't use fieldsets or legends. Of course, I'm not. That is the right way to do it. But just be mindful of that.

So, as I said, current AT reads out legend and then puts the label on afterwards. Keep the legend short really. That's one of the kind of pieces of advice I would. Because we know how the screen readers operate. Keep it short and ensure that the fieldset is actually wrapping up all the related kind of form inputs. So, just being careful what you're wrapping up so that you don't get kind of bizarre things where you did say, "This is a fieldset for personal details." And then you just forget, and you slip in some input that is completely irrelevant and that should actually be in the next section. And as I say, if you can't avoid it, don't use fieldset or legend. It's up to you. Again, you need to weigh up the kind of cost/benefit for that.

accesskey attribute

Accesskeys. WCAG helpfully told us, again, that providing keyboard shortcuts to import links and form controls and groups of form controls would be a really good thing for accessibility. It certainly is. Come on. I use them myself, a very limited set on the University of Salford site, just a few basic ones. Accesskey, one, two. Basically, activate the link back to the home page. Four to actually put the focus on the search box. Zero to go to the help and accessibility kind of section of the site. There is another one I use, too, which we'll see later. It basically activates the skip link to go to the actual content. So, that's quite a judicious kind of use I would say of accesskeys.

Now, remember not every link on your site or every link on your navigation with 25 elements is that important that it needs an accesskey. Depending on how many accesskeys you have got, they're only useful is the users can actually remember or kind of find out what they are. I'm always reminded of back in the days when I used to play like flight simulators. You used to get like little things you could put over your keyboard which showed every keystroke, what it actually does. Jettison cargo and things like that. I don't know. So, if you're stuffing your page with loads of accesskeys, chances are users aren't going to learn every single accesskey for your site. Especially if it's a site they're only likely to visit once or twice when they actually need to do something.

If it's more of a day-to-day kind of activity like you work in an organization, and you've got a walled garden, you just got your intranet. You can't actually go out, and everything happens through that site… yes, you might add a few more accesskeys to kind of make day-to-day work easier for certain people. But it's difficult to actually choose a large set of accesskeys because accesskeys are limited to single character combinations. On most browsers on the Windows platform, they're triggered by using alt and then a single key. So, you're already limited by the number of accesskeys you could have. So, even if you wanted to have 60 accesskeys, you can't physically have them. Also, you need to be aware of because it uses alt in Internet Explorer, and I think Firefox still… Although you can change that. It will end up…you will end up getting conflicts with not only on the page but actually with the browser.

So, alt 8 will actually trigger the help kind of dial up of the browser. You might even end up triggering things of the operating system. Or if there is assistive technology that's running on top of your operating system, chances are you might even trigger some kind of other function of that. And that's not just the English version. A lot of people I've seen started kind of going through, "All right. Well, I'll document every single shortcut key that's actually used say by Windows or by IE." But that is only for the English version. How can you guarantee that say the German version doesn't use a different shortcut for that particular menu? Because obviously they use something that makes sense in their particular language.

So, once you really whittle it down, the only kind of mildly safe kind of things you can use are pretty much just the numbers. I think there was even something with alt 1 triggered some certain screen reader's kind of dialogue as well. So, even the numbers aren't safe. Another UK government accesskey standard let's call it that suggests like these various kinds of…using all the numbers and the S key to skip. That is all right. On the Salford site, I've adapted just four or five because it uses numbers. But, again, as I said, that's something to be aware of. There might be conflicts. If you're actually following the standard there might be issues in certain combinations. So, just be mindful and not kind of thinking at all costs, "I need to add an accesskey to every single link on my site because that's important." Because you get diminishing returns if you put too many in. Users won't remember them.

tabindex attribute

tabindex attributes. That's another kind of back from the dark ages of HTML really attribute. WCAG tells us that we should create a logical tab order through our links, form controls, objects. So, as you go through the page just using the keyboard, you're not going to jump left, right, and center. It's got to make some kind of sense. So, we've got tabindex as the attribute, which can be added to links and form controls for instance. And here just as a classic example, I had to look hard nowadays to find good examples that use tabindex. It's WordPress. I believe that the current version… If you install WordPress, a little blog platform, it still kind of tries helpfully to put tabindex in your comment box in the default template.

So, you install a fresh install WordPress, it puts that stuff in. That's great. They don't necessarily need to actually do that because if you look in the source code, the source order itself is your kind of default tab order. So, the way… If a link comes before the other one in the actual source, HTML, that link will be tabbed to first. So, they didn't necessarily need to do that. But I get the feeling they thought, "Okay, well, let's be overly good." Accessibility plus again. Which is great. However, as soon as you get to any site that's run with WordPress, your first tab… Say you get through an article page, and you don't necessarily have to be a screen reader user… You could be a sighted user just using a keyboard. Your first tab if you want to navigate through, you actually end up having to type your name in. Because when you got tabindex, anything with a tabindex takes precedence over anything that hasn't got a tabindex.

So, on this particular page, tabindex one, two, three, four, five for the submit. They're the first five tabs on that page. I get to the page. I want to just kind of tab to the next link to kind of work my way down the article. And I'm already at the bottom of the article, and it's prompting me "do I want to comment". No, not really. I just want to work my way through. So, things like… They're trying to be overly helpful. It can be a usability issue. So, in this particular case the best thing they could have done is just leave that tabindex attribute out. The user will find his or her way to that common form naturally as they progress through the page because the markup, the source order is actually okay already.

Oh, Christ. Okey-doke. tabindex was very helpful when you use it to do table-based layouts because you start it kind of putting things around. But nowadays you can control a lot of it with source order, making a logical tab order in the source. And if you need to, using kind of a bit of judicious CSS positioning if you must. As I mentioned, everything that's got tabindex takes precedence over anything that hasn't. So, just putting one single tabindex would mean that that is the first link to get to. It doesn't control the local kind of in that form, the tabbing order. It controls it for the entire page. And just a little caveat that applies both to tabindex and to using CSS positioning, you should avoid doing too kind of complex rearranging of the tab order visually from the source code.

Because, again, that could get very confusing. Somebody with screen magnification might not quite understand how your page works if every tab takes you, "Oh, this goes top left, top right," etc., etc. It should really be a good kind of… You should follow the layout of the page in general with your tabindex in my view.

Skip links

WCAG tells us group related links identify the groups and until user agents do so, provide a way to bypass these groups. Now, as an example on the Salford site, on the left we got the navigation. That's obviously all links. Say somebody gets to this particular page, and they want to just jump straight to the content. Just purely if they don't know any other shortcuts and if they're not using any assistive technology, there is no easy way for them to just jump straight to the actual, "It's simple, Manchester is one of the most exciting cities," blah, blah, blah.

So, what I've done is I've added a skip link, but I've actually kind of used a bit of CSS so that it's not there by default. You don't see it by default. But when you actually put the focus on it, it appears. It appears in a logical place so somebody who might be using screen magnification or whatever, they're not going to be surprised because all of a sudden, they're all the way off to the right, etc., etc. It's in a predictable place. It doesn't impinge on the graphic design. That's fine. So, you don't have to battle with your graphic designer. But you can still actually put a skip link in there. And when they activate that, they end up in the right place on the content. Is anybody from the DRC here? Just working out if I'm going to get lynched at the end of this presentation. Okay.

No, it's not that bad. The DRC website, it's quite interesting. They've actually got seven links that are hidden there. You actually don't find them, which I find is really confusing for if I'm a sighted keyboard user. Because the first seven tabs actually go nowhere, and only after the seventh one you start getting like email, bulletin, etc. But they've kind of went a little bit further. Oh, one skip link is good. Let's add two. And actually, well, it's three. Two go to the same place. So, the first one, right at the beginning, you've got two skip links. Skip, global navigation, and then jump to main content. If you just activate a skip, global navigation, you end up just after newsroom basically with another skip link that says, "Now do you want to skip the local navigation," basically. And end up to the content. Is that overkill? You could argue that.

Some browsers and some specific technology, depending on what you use, already offer you a better way to navigate. This is very valid. Skip links are very useful for users that don't use anything other than IE. They might be sighted users. If they're using screen readers, they already got quite a complex way of interacting with the page built into the screen reader. They can jump to different headings. They can get a list of links, etc., etc. If you're an Opera user, you can also do that – jump to different headings, etc. But for the real baseline kind of IE user with a keyboard, that is a valid thing. Just don't go crazy with them really.

And some people might argue you should always have them visible. I would say definitely you shouldn't have them always hidden, like the DRC website. But you can probably meet somewhere halfway with something along the lines of that. I did with… Well, not just me. It's a technique that's been used on some sites. That it's just the skip link appears in a predictable location when you actually put the focus to it. I'm just going to drop it right there at the end. Does that apply for back to top links as well? There are already key combinations to actually jump back to top. Do we really need to litter our pages with back to top? I don't know. I'm just going to throw that into the room.

Text size widgets and co.

Now, I'm going to try and keep that short. This is a personal bug bear of mine. It kind of… It's one of those, "Let's add this feature to make it even more accessible." And I'm going to have to keep it short, so I'm going to do a mega rant. If previous stuff was opinionated, this is even more opinionated. Text size widgets. This is the first time I ever spotted one I remember a few years ago. What do I know, Todd Dominey… He's a kind of graphic designer. He added this sort of text resizer. And since then, they've appeared everywhere. Second mention of the DRC website, because they went with the kitchen sink approach that's, "Let's put everything on this site." So, you can change the text size, and you can also change the colors. I'm not going to touch on the color side.

And even at my institution, even though I've told my web authors, the various web authors in the schools, don't do it, somebody went ahead and did it. And I found out… A little anecdote in the end. I found out that the reason they did it, they've got a research institute for accessibility in the built environment, and it just so happens that apparently the web master for the DRC is doing a PhD there at that research institute. So, they just kind of went ahead and added his thing to their site.

All right. Why do I hate them so much? This is kind of the fundamentalist me.

My belief, they emulate browser behavior. Along the same lines as having a link that says, "Print this page," or, "Bookmark this page," or things like that. You can already do that. Unless your site is built in such an awful way that you need to provide this functionality to override whatever is happening, users can already resize the test. It is a usability concern if you start cluttering your pages with all these kinds of widgets everywhere. What happens if you're linking to an external site? Yeah, you might be doing it, saying, "I'm doing all these kind of people with low vision a real big favor." But then I'm linking out to another site. Once they're there, it's outside my control to stop them. I don't care. I just wanted to make sure that my site works nicely.

And the settings don't carry across. Even if two separate sites use exactly the same script, if I set my size because I need it a certain size on this size, I go over to the site, it doesn't carry across. Because the cookies are the main specific that I set. On the school side, that's what they did. Actually, the Salford, kind of the various schools within the Salford domain, all live on different kind of subdomains. And they've got a few sites now that are using this, it's kind of spread in that school. And yeah, you set it on one site, on that school's website. You move off to the research institute for that particular school, and the size is back down to the default. And you still have to change it, so they didn't even implement it in a smart way.

But yeah… Five minutes, okay. But the argument always is, "But users don't know they can resize the text. My mother doesn't know that she can resize the text," etc. It's a valid point. So, how do we solve this thing? Really in my view it's the browser developers that should be doing more to actually make sure that the option to resize is clearly visible. For Firefox, I wrote one of the first kind of little extensions. It's not rocket science. It's just a little extension. You install it, and it gives you direct visible access to the default text resize options. Why is something like that not default? It's getting better though. The latest version of IE has now got still a bit hidden away, but they've got their zoom feature, which is not just text size, it's the whole page. So, hopefully, hopefully as more and more browsers start to kind of adopt this, we'll be able to actually remove… The argument of "users don't know" starts to kind of lose a bit of traction.

And as Alastair Campbell at Nomensa wrote recently… That's, again, a horribly visible link. It is a usability gap. I can sit here and be all hard line about it, but if you actually have got users that are over a certain age or low vision, users with dyslexia that need kind of certain adjustments, it is useful for them. Mainly because they don't know they can already do that. But yeah, browsers should make that obvious. In the meantime though, I would say the best approach is not give a man a fish but actually teach them fishing instead or how to fish. BBC website recently, they've added on their homepage display options and accessibility help. Now, display options is pretty much the similar kind of approach. You can do all your settings, and it actually gives you a nice preview. But what I'm really interested in is… Come on.

No. I'm interested in it, PowerPoint isn't. There we go. As I already mentioned before, they also when you do disability help, they link you to My Web, My Way, which explains to you how you can actually change your settings. And I'm caving in now at Salford in terms of this text resizer because there's so many people that are kind of calling me an accessibility Satan now for not implementing it. But I'm going to have a more subtle approach similar to the BBC. I'm definitely not sticking big kind of buttons there, say A+, A-, which can actually confuse certain types of users if you're moving around and you don't now what they are. You click them by mistake, etc. Or you put all the different color options. It gets very confusing and cluttered. I'm going to have one page where you can actually set something really basic. You can set your basic text sizes and colors possibly. But I'm going to have a very prominent link to this, which explains how you can actually do it permanently. Because it's a lot better. Once the user knows that he or she can change it then you can link out safely to other sites and now that they're not going to get completely lost.

So, you're actually doing them a favor. Two minutes. Wow, I have to go to the conclusion. Right.

Conclusion?

Conclusion then is with all these things, all the accessibility kind of things that you can do with sites is great. It's great knowing that you can use alt. You can use tabindex. You can use accesskey. The key really is understanding how users operate your site, as I refer you back to the example of "poor screen reader users that need to listen through the entire page". No. You need to understand how users operate it. And obviously if you don't know, get organizations like the Shaw Trust, etc. They will be able to help you or put you in contact. You might be able to sit in on a testing session, etc. And yeah, related to that, you need to be aware of how current browsers and assistive technology actually behavior.

Don't base all your knowledge just on the 1999 WCAG which was probably quite right at the time, but things have moved on. All the until user agent things are pretty much solved now. And don't just do it for the sake of it. Like the tabindex thing on WordPress I would say was an example of, "Let's just stick that in as well. That will make it extra, extra accessible." And of course, text sized widgets are evil, and I hate them.

So, that's the takeaway from this session really. And thank you very much. Hopefully I've got some audio recording here. There will hopefully be some audio and transcripts, etc., available and the slides as well. Thank you.

Patrick H. Lauke / Public Sector Forums / 8 August 2007 / Barbican, London

Creative Commons Attribution Non-Commercial Share-Alike license