Skip to content →

Tag: Web Accessibility

The deal with opening hyperlinks in a new window or tab.

The main consensus is to avoid them. Why you say? Well because it’s not necessary. If you really want to open a link in another tab or window, you can do it yourself:

In Firefox, hover over the link you want to access, right-click your mouse to get a menu and click on “Open Link in New Tab” or “Open Link in New Window”.

Firefox Right Click Menu

In Internet Explorer, hover over the link you want to access, right-click your mouse to get a menu and click on “Open in New Tab” or “Open in New Window”.

Internet Explorer Right Click Menu

I found other compelling reasons to avoid this habit on Accessify Forum. Kyle J. Lamson wrote“…Forcing new windows can confuse people when it opens behind the window and they do not realize it and it is really iritating when we are reading and it blocks our view.” He also mentions that some browsers or applications do not support multiple windows. He continues by adding “If I want to return to your site, I will… either back button or because usually I open links in new tabs. But if I am just using your site as a jump off point to somewhere else… then i do not wish to remain at your site and you should not force me to.”

I agree with Kyle, it’s all about giving choices and not forcing anything on the user.

So use the back button or get to know your browser. Simple and efficient shortcuts will help make your web browsing experience a better one.

Leave a Comment

Accessible Web Search for the Visually Impaired

Google cleaned up their search experience with their accessible search engine. Fairly similar to the regular search, but with some subtle differences that can aid a visually impaired person to search better.  The system is still being developed but basically it prioritizes results that are accessible.

Check it out a: Accessible Web Search at Google

To learn more: Making Search Accessible to Visually Impaired Users and Is your Web Site Optimized for Accessible Search?

Leave a Comment

Pretty and accessible design

It is more and more apparent that accessibility can be beautiful. I came across Accessibility in Focus, a website for an accessible web award.

There was 4 finalist, one of them was the Salford City Council. A fairly large website. Its navigation is straightforward even if at first glance the site looks overwhelming. This site is proof that the size of a website is no excuse for accessibility.

The interactive award winner uses Flash. Although Orange Project conforms to the lowest priority level of the W3C WAI standards, I still think that Flash has a long way to go. While considering the site’s probable target audience, the design is a very successful one.

4 Comments

Reviewing an authoring tool

I was going to do an evaluation of an authoring tool, but the WAI have thought of it already at www.w3.org/WAI/AU/2002/tools.

I found that the reviews were all a little outdated and I didn’t get a definite conclusion from any review. So I finally decided to go ahead and check out an authoring tool myself. I went for the markup editor developed in collaboration with the W3C, Amaya. It’s a WYSIWYG editor/browser. Many distributions are available. I will be looking at the Windows one.

I opened an existing file that I know is made to standard and it came out all distorted. I then created a page from scratch. I must admit that I’m not used to any kind of authoring tool. I have been using Notepad++ for a while. So it was a little strange. At first it took me some time to get used to the application itself, but after a while of playing with it, it was fairly simple to use. I did a trivial page with a menu, an unordered list, a form and an image.
Page done with Amaya

Page done with authoring tool Amaya
Page done with authoring tool Amaya

Formatting done to some text resulted in inlining style, there were extra open and close paragraphs, inserting the image required to enter an alternative text, and as for the other elements they were pretty intuitive.

It’s clear that you still need to know some basic concepts in web standards to make any web page complaint or accessible. This tool might be good for someone just starting, but I think I’ll just stay with my simple text editor.

Leave a Comment

Evaluating a website for accessibility

The W3C has extensive information on how to properly evaluation a sites accessibility. Here are the underlining steps to ensure that your evaluation is full-proof:

For a preliminary review, select a page that is representative of the whole site or that most people will see. Try to choose a page that has tabular data, images and scripts. And then:

  • Examine this page for alternative text,
  • Divs instead of tables for page layout,
  • Use the keyboard instead of the mouse for navigation,
  • Test with different font-sizes and screen resolutions.

The Firebug and Web Developer extensions in Firefox will make your life easier in accessing the code and disabling images and even resizing your browser size. It might be a good idea to try a screen reader, and not to mention an Web accessibility evaluation tool like AChecker. These will enhance your understanding of the sites limitations and successes.

Another important part of evaluating a site is to get people with disabilities involved in the process. Some may have insights that other users will not.

For a complete procedure of website evaluation you have to go to the W3C – Web Accessibility Initiative page.

Although a little outdated, the WAI also provides a comprehensive checklist of accessibility guidelines (WCAG 1.0) and an useful template for the final accessibility report. They really thought of everything!

One Comment

Case Study

So I recently re-did one of my old websites. My client wanted to had some images so I took the opportunity to give her an accessible site. I had done this site a few years ago. I wasn’t aware back then of web standards and web accessibility. I must confess of using tables for layout. But alas, I have done right by this website. I gutted it and made it new again. Although you can’t really see the difference between before and after! Let me show you what I mean:

Contact page before
Contact page before
Contact page after
Contact page after

They don’t look different, but I did change the code.

Here’s what I did:

  • I started by getting rid of the tables for layout purposes. I know!!! It’s all gone now.
  • Then I added the language to the html tag, lang=”en-US”, like this <html xmlns=”http://www.w3.org/1999/xhtml” lang=”en-US”>
  • I gave a more complete title to each page, like “Nadia Stevens Jin Shin Do Bodymind Acupressure Montreal”.
  • I repositionned some divs and wrapped them properly. Some classes and ids were not correctly placed, so I had to fix these. For instance, I had the same id used several times in the same file, so I changed these to classes.
  • Some images had misleading or inaccurate alternative text. Instead of “Fire” as the alt attribute for a chinese character representing fire, I wrote “Fire character”. In the instance where I had images that were not content related I made them blank text, like this: alt=””.
  • I got rid of widths and height attributes.
  • The menu of the page was not in a list, so a placed it in an unordered list.
  • For the maps, I added an onfocus attribute to every onmouseover attribute  and I added an onblur attribute to every onmouseout attribute.

The first page took me about 3 hours, additional pages took me 1 hour to 2 hours to renovate in the same way.

Ok so this site was easy to do because I had already a lot of div’s in the first place, but it really gave me an idea of how many things need to be thought of while in the process of revamping a site. This work is meticulous and a little repetitive, but if done with methodology, making any site accessible can be pretty painless.

Leave a Comment

Podcast Five – Advanced Accessibility

[podcast]http://thinkingaccessible.com/podcasts/advanced_accessibility_podcast_five.mp3[/podcast]

Transcript of the podcast:

[Intro music] Welcome to podcast five of Thinking Accessible. On today’s podcast I will talk to you about some advanced features in accessibility.

First on the menu I will talk about accesskeys. Accesskeys are keystrokes that we can trigger on the keyboard to go directly to a certain element or a certain page of your website. Accesskeys are to be combined with different HTML attributes, different HTML tags: the a, the area, the button, the input, the label, the legend, and the textarea. These are your choices for accesskeys. It’s recommended to use numbers 1 to 0 (o to 9). Don’t get carried away! As long as you have shortcuts to important links, this should suffice. For example, the UK has established standards for their accesskeys and they have a list of 11 shortcuts (that they deem important to use.) I would recommend to look at these options and choose the most appropriate ones for your web page.

For my blog, at thinkingaccessible.com, I will only need skip navigation which is the S keystroke, home page which is the 1 keystroke, search which is good and is the keystroke number 4, and accesskey details which is the page that explains the accesskeys used and this is the keystroke zero.

For every accesskey, it is a good idea to put a title with it, to explain exactly where it is redirecting the user.

For example, the accesskey 1 which will be going to the home page, you can title it: “Back to the home page. Accesskey 1″.

Ex:

<a href=”home.html” title=”Back to the home page. Accesskey 1″ accesskey=”1″>Home</a>

I got all this information through a really great article. You can check it out through a link on my blog: Article on Accesskeys

Next up, I think it’s important to discuss labelling forms. Once you get this, it’s super simple! Let’s look at a really basic example. For instance, we have a field for a name, so you type in Name for your label and then you have your input. For this example let’s say that the name attribute is “fullname”. Now for it to be accessible we need to add a label tag to the label itself. In this case, the label we have is Name:, we have to wrap it with the label tag and then we have to for attribute. This for attribute can also be called “fullname”, but remember that your input has to have an id with the same exact name. These two things work together, the for of the label and the id of the input. They work as a combination.

Like this: <label for=”fullname”>Name:</label> <input id=”fullname” name=”fullname”/ >

That’s basically it, that’s all you need to remember.

I have a link to the article in which I got this information: Article on Labelling forms.

My next topic is CSS relative font size. Why is it important to put relative font sizes? It’s for people to be able to change the size of the text in whichever browser they use. Nowadays the more modern browsers zoom the page, so this is not a big issue, but the older browsers have the old way of doing things that was to increase the size, but if this size is an absolute size then it won’t move, it won’t budge. But if it is relative size then it will relatively expand or diminish depending on what the user does. This is why it’s important to do this.

The way of implementing this is that your main body, the main text that you use at the beginning of your CSS stylesheet make it an absolute to the size you want most of your page to be that way you don’t have to worry about it in the future. Some people put 12, I like to put 14 px, pixels. But it’s really up to you. All the subsequent font sizes that you use on your CSS stylesheet, should be a relative number. Either use ems or percentages because it’s much easier to follow.

[Exit music] Well that’s it for today’s podcast. I would love to hear from you. Please come to my blog at thinkingaccessible.com and post some comments. Until next time!

Audio from ccMixter entitled “Café Connection“ by Morgantj under Creative Commons.  Creative Commons by Attribution 3

Leave a Comment

Did you know that…

Did you know that according to Statistics Canada in 2006 there was 1,289,420 Canadians with a hearing impairment, 835,960 Canadians with a seeing impairment, 2,856,820 Canadians with an agility impairment, and 752,110 Canadians with a learning impairment. In every case, around 70% of these Canadians said that they had used the Internet in the past year. Let me crunch the numbers.  That’s 5,734,310 Canadians with the above mentioned impairments of 31,612,897, the total population recorded that year. So…there’s roughly about 13% of Canadians, with these impairments, that use the Internet.  That’s a lot of people if you ask me!

Ok, nobody likes having numbers thrown at them, but I hope that at least it impresses on you how important it is to consider people with impairments or disabilities as active members of our society and as such they should to be able to access with ease all the information everyone else can access.

You can have a look at the complete survey at the Statistics Canada website.

Leave a Comment

Another Firefox add-on

Don’t you just love Firefox add-ons. I do! Especially because they make my life easier.

As a developer it is important to have a feel for what the user is getting out of your site. I found a good way to use a screen reader on any operating system (OS) without paying a dime. I am using Fire Vox. It utilizes the integrated screen reader application of any OS (Windows, MAC and Linux) and functions on your Firefox as an add-on. I tested it on a Windows XP and it worked pretty well. I got some choppiness in the sound but this is probably due to my old hardware. The only downfall for me is that I cannot easily turn it off. I would have liked to have this feature in the Fire Voxes options, but instead I have to go to the add-ons extensions list and completely disable it. Oh well, I’ll live

One Comment

Podcast Three – My four golden rules

[podcast]http://thinkingaccessible.com/podcasts/four_golden_rules_podcast_three.mp3[/podcast]

Transcript of the podcast:

[Intro music] Welcome to podcast three of Thinking Accessible. On today’s podcast, I will talk to you about my four golden rules for web accessibility.

Rule number 1:

Provide alternative text for non-textual content. What do it mean by this? Images are non-textual content. Audio and video are non-textual content. So for each of these elements you need to provide a text alternative. So for images in the HTML code you have to write an alternative tag to it. So in the tag of IMG for image you have to add ALT. for alternative text and here you would put basically a general idea of what the image represents.For audio feed, like for example this podcast, it would be nice to put a transcript of the audio because some people might not be able to hear it. And for video, you should put obviously captions for all the text (speech) in the video. Sure these are not easy to do, there are time consuming, but in the end it is good, for one, the person that cannot hear or see you media and also for search engines, because they will actually have the textual reference for these medias. So it’s a win, win situation.

Rule number 2:

Make it simple and consistent. Making your website simple will help people with cognitive impairments, elderly people and new web users that are not used to big and elaborate websites. Consistency is also important because if you have a lack of consistency your user might be confused, won’t know what’s going on with the website, might be lost. So we want to minimize this because if a user feels frustrated in your website, they are more likely to leave that website and go somewhere else. You can make your website simple by simply (sorry for this repetition) using normal vocabulary that anybody can understand. Do not be too verbose and just be clear with what you can to express. Consistency is to basically keep the same layout through out your website and you should be fine.

Rule number 3:

Colour contrast. In order to make your website legible it is important to consider colour. For example if you want to have a black background you shouldn’t really consider a colour for the text to be dark grey because this will be illegible for a lot of people. For me this rule is just for you to use common sense. I mean if you think that the colours you have chosen for the foreground and the background are not going to be legible or not easily legible by let’s say your grandmother, then don’t use them because it won’t be legible for a lot more people.

Rule number 4:

The last rule. Respect those HTML tags. Ok, so here it is. If it’s a <p> tag, then it’s a paragraph, then use it as a paragraph. If it’s a <table> tag, then use it as a table. Tables should (only) be used for tabular data, for example a data in a spreadsheet and not for layout, not for your page layout. (Use CSS instead!)

So those are my four golden rules for web accessibility. Yes, I know, there’s more to it than that, but for just a quick rundown of the essential ideas in web accessibility, these four simple rules are a major step forward.

[Exit music] Well that’s it for today’s podcast. That was podcast three for Thinking Accessible. My name is Rocío. Until next time!

Audio from ccMixter entitled “Café Connection“ by Morgantj under Creative Commons. Creative Commons by-3

Leave a Comment