Accessibility – Page 23 – Customer Servant Consultancy

Anyone who has ever used GitHub with a screen reader knows how painful it can be. This makes contributing to, or even reporting bugs to, projects hosted on the service difficult, and there are a lot of those projects that are large and popular and that could definitely use the help when it comes to their accessibility issues.

Luckily, as long as you’re using Firefox or Chrome, (sorry Internet Explorer users, no help for you), There’s a solution for this problem.

Enter Greasemonkey

Greasemonkey,(and its Chrome equivalent, Tampermonkey), allows you to run user-created scripts in your browser so that you can change the way a website behaves. This includes making it more accessible.

[Tweet “Greasemonkey is like Smart Web except you don’t have to pay for an SMA to get access.”]

Wait, are you saying website creators don’t have to make their sites accessible?

Absolutely not. What I am saying is that when you have no control over whether or not a website like GitHub is accessible, and you have no choice but to use said website, Greasemonkey is the next best option.

Installing Greasemonkey

To install Greasemonkey, navigate to the tools menu by pressing alt+t. Then, arrow down to addons. Alternatively, you can press ctrl+shift+a to open the addons manager. Next,tab to the list view and make sure “get add-ons” is selected. After this,tab to the edit field type “Greasemonkey” in the field and press enter.

Once you press enter, you can either tab to the list of add-ons and select the one you want to install, or tab through the sort buttons and sort the results accordingly. Once you’re in the list of add-ons, arrow to the one you want to install and then tab to the “install” button and press enter or space.

You’ll need to restart Firefox for the Greasemonkey add-on to take effect. You can restart when prompted or restart later.

Make GitHub more accessible

Once you’ve installed Greasemonkey, install the Greasemonkey script for GitHub by Jamie Teh of NVDA fame. As long as you have Greasemonkey installed, you can press enter on the link to the GitHub repository and Greasemonkey will happily install it. It will ask you if you’re sure, warn you about how user scripts can do bad things, but this one’s fine so go ahead and install it.

The GitHub site is magically a lot less painful

Once you have this script installed, the GitHub website becomes a lot easier to use with a screen reader. This is a tool you definitely have to have in your toolkit if you’re doing anything with GitHub, regardless of whether or not you’re using it to host your own repositories. If it makes your life easier, consider a donation to NVAccess.

Advice for maintainers of popular open source projects
This talk from this year’s WordCamp Europe is something that’s worth looking at even if you’re not the maintainer of a popular open source project. A lot of what’s here is also good advice for contributors, especially long-time ones, and I think the whole thing is valuable reading especially for free software/open source projects within the accessibility space in general and the adaptive technology space in particular. Compared to the spread of open source in general, the adoption of open source within the accessibility space is still in its infancy, and it has some domain-specific hurtles that have to be overcome. I’m thinking of all the patents and trademarks related to this industry here. I personally believe that accessibility-related materials and tools should be free software or Creative-Commons licensed by default, but I can also understand at least in some cases why the risk is deemed to be too high by some creators. And because I’m reasonably certain that explaining why I don’t believe it’s OK in other cases would ignite a ton of controversy, and I don’t have time to deal with a lot of that this week, I’ll refrain from doing so. If you’re really interested, you can ask me privately.

When your website is accessible, all users can access your content no matter their abilities. Visually-impaired users can visit your website using a screen reader. Those who can’t, (or prefer not to), use a mouse can navigate your site using a keyboard or other input device. Some accessibility features might also improve your SEO. When your site is inaccessible, research shows you could be excluding up to 20 percent of your users. This talk for all skill levels will review tools and techniques you can use to test and improve your site’s accessibility.

This talk by Rachel Carden at this year’s WordCamp Miami. Click here to view the presentation slides. If you’re using a screen reader to view the slides, navigate to the title of the talk at heading level three and read from there.

Semantic HTML is one of those things that comes up in every accessibility talk. If you’re a developer, you’re probably tired of hearing about it. The thing is though that it’s vitally important, and is the foundation of every accessible thing on the web. It’s also the foundation you need to start with if you’re trying to make that cool thing you’re building accessible to everyone, no matter what kind of device they use to access your site or web application.

Léonie Watson has posted a very well-written article explaining what “semantic” means in the context of the web, along with some demonstrations. It’s worth a read for anyone who’s making things on the web, (including people who don’t consider themselves developers), and it can serve as a quick reference to file away for later when you’re in the middle of building and you need a reference.

If you’re building a product for the web that has a user interface as a feature, (and let’s face it, most of them do), you may be tempted to build your own custom UI elements.

Don’t do that.

For one thing, you’re reinventing a wheel that’s worked well now for a very long time. For another, you’re creating more work for yourself. And finally, it’s bad for accessibility, which effects a lot of users, and I don’t just mean blind ones.

The following video illustrates what can go wrong when you decide to reinvent the UI elements wheel.

If I shouldn’t build my own elements, what can I do instead?

The easiest way to get accessible UI elements is to use already-existing elements under the hood. HTML already provides the elements you’ll need, (radio buttons, checkboxes, comboboxes, and the like), and if you opt for already-existing elements instead of building your own, you’ll be saving yourself a lot of time, and you’ll be working smarter, not harder, to build your application. Which means you can shove it out the door faster, make a lot of people happy, and probably save some money too. What’s not to love.

so the next time you’re tempted to build your own elements, ask yourself:

What am I gaining by building a custom element that I wouldn’t get by using an already-existing one?
If I build custom elements, I may be making my application or plugin harder to use for non-developers. Are all the extra support questions and complaints worth it?
I’m spending more time, and therefore more money, on my project because I’m building custom elements. Is the extra cost worth it?

I think, if you keep these questions in mind when starting to build your user interface, and if you answer them the way I think you will, you’ll have enough justification for sticking with what works before you even bring accessibility into the picture. And if you are inclined towards making the web a better place for everyone regardless of ability, that then becomes icing on the cake.

A Second Opinion

Sina Bahram of Prime Access Consulting, a firm specializing in universal design and accessibility, disagrees with the above opinion and offers the following instead:

I recommend we do not phrase accessibility as something antithetical to what many developers do regularly. I try not to tell developers to deviate from their existing practice, but instead try working with them on improving their existing methodologies to make their creations more inclusive to all audiences. If any developers are interested, I am happy to discuss when custom UI components are appropriate, and how to then make them fully inclusive. Semantic markup, reuse of existing controls, and adherence to solid web development principles are great things to keep in mind when developing novel interfaces. When the need and desire for innovation arises, it is important to realize that new interfaces have the same potential to be fully accessible as current native ones, but it takes a little bit of extra work. I’m happy to discuss further. You can reach me at @SinaBahram on Twitter or
via any other means found at my contact page.

If any other accessibility authorities wish to add their opinions, feel free to ping me and I’ll be happy to add those as well.

Update:

This article was originally posted at A List Apart, and generated a lot of very thoughtful and insightful comments. It has since been taken down, and re-posted at Heather Burns’ site. It’s always a sad thing when big-name web publications sensor in order to avoid or deflect controversy.

Digital legislation is confusing and outdated—Heather Burns shows how professionalizing the web industry can help.

Source: The Perfect Storm in Digital Law

This entire article is worth a thoughtful read, and I think it has implications for not only those of us who work as web professionals generally, but accessibility professionals in particular as well.

Specifically, the accessibility profession is going to have to join the greater web profession in working towards a solution to the problems outlined here, and in order to do that, it’s going to have to become a lot less insular. It’s going to have to learn to play well with the greater web community, regardless of whether or not that community as a whole has signed onto accessibility as a right and obligation.

In other words, every one of us is going to have to shelve our pride in whatever we work on and learn to play ball professionally witheach other and other communities who are going to have to come under our umbrella, because we’re up the creek if we don’t get it together.