Category: Learning From The Community

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.

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.

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.

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.

Back in the bad old days, before the WordPress Accessibility Team really got off the ground and came into its own as a well-loved and respected part of the WordPress project, I used to see a lot of claims from theme vendors, page builder vendors, and plugin authors, (both free and premium), that their products were accessible, or sec. 508 compliant, or the like. Thanks to the work of the accessibility team, and its individual members, that is no longer the case. Not only are plugin and theme authors less likely to declare their products accessible without asking someone to check it, (or paying for work in some cases to ensure that their products are in fact accessible), the term accessible has been more or less swopped out for accessibility-ready, meaning that you can create an accessible site with it, but there’s also room to make your site less accessible by not following the author’s recommendations for settings. All of this makes me very proud. We’re making progress towards full inclusion for everybody, regardless of ability or language spoken, and we’re also making sure we point out where we still have room to grow.

Some of Adrian’s techniques from the linked post above will work in this ecosystem, and some won’t. But either way, this is a great roadmap for users who are either downloading or purchasing premium products to test claims of accessibility if any are made. The testing technique, and the filing issues technique, are also great ways for users or other developers to help the process of “make accessible all the things” move forward. Just make sure you’re polite and respectful when filing reports. The difference here, as with other open source projects, is that the majority of the time, these developers are putting their free time into these projects, and do not have dollars to spend on proper accessibility consulting or remediation.