Google summer of code

I never claimed to be much of a blogger so, sorry for the lack of updates.

While my updates stopped, my work did not. I have learned a lot this summer when it comes to web accessibility and that is exactly why I choose to do this project. I can say that from what I have seen a11y is a very subjective thing. There are a wide range of disabilities and a wide range of issues that fall under each specific disability. It is nearly impossible to account for every issue that may come up when accessing a website but I think I’ve come to a point where I can simplify things for developers who aren’t concerned with a11y.

1. Try to navigate your site using a screen reader. Google has a free screenreader for both firefox and chrome as a plugin.
2. Most web a11y issues come from web2.0 elements. Learn to use ARIA to describe what these elements do. (See discussion below)
3. Be sure to avoid using images for things that can be presented with css/text
4. If you need to use images be sure to describe what the image is or what it is for (use alt tags).
5. Check color contrast, there are tons of free tools that will show you how a page looks with different types of color deficits.
6. Valid html is the base for a11y
7. Try to navigate your site without the mouse- some people have limited motor skills and navigate the www with the tab key. Tabindex=0 will make something tab-able.
8. If you have audio or video make sure it is captioned, there are many paid services that do this, but it is very easy if your video or audio has a script. You just need a captioning tool and there are tons of free tools online
9. Make sure your website is logical so people understand what to do and how to navigate it
10. and lastly add jump links so people with screen readers can skip over repeated content between pages

In my work a major issue was popups. HTML was designed to be static, and until we get a better version of html with tags of all the widgets people normally use (think popups, sliders, moveable content, etc.) we need to use workarounds like aria and javascript to make a site accessible. An interesting discussion comes from this but to keep it simple: When we develop windows applications the “widgets” are built in. There is a special widget you can place in your application called a “slider” that has a “min” and “max”. A html version of this is a “div” with a “div” and some text. How is a webbrowser or screenreader suppose to  kn0w what the div is for? It can’t. That is why we have ARIA tags. ARIA is used to describe what an element is used for- it tells a screen reader that a “div” is actually a “slider” and defines the “min” and “max”. Aria attributes can also be used with javascript to specify data. For example:

Instead of:

<div id="slider" data-min="0" data-max="10" data-value="4" />

Use:

<div role="slider" aria-valuemin="0" aria-valuemax="10" aria-valuenow="4" />

This allows you to have the same information while maintaining accessibility. I will be suggesting jquery and other libraries use this method to increase accessibility.

I will be continuing on my a11y path of construction to make the www a better place for people with disabilities. All it takes is awareness

I am super excited to be part of GSOC, especially doing web accessibility. Both google and Mozilla have a deep understanding  of the importance of access to information, but an often overlooked area is access for users with disabilities. This summer I will be exploring and improving my understanding of making web 2.0 interfaces accessible to users who may require special tools to access information. This may be anything from an on-screen magnifier to a mouseless interface, even a screen reader for the visually impaired.

It is our duty to ensure everyone has equal access. I am proud to be aware of these issues and look forward to learning and discovering new ways of allowing access to information- especially with a project like openbadges which already has such goals in mind.