I am currently working as an accessibility specialist for Catalyst IT Ltd. Catalyst is the leading open source company in New Zealand. We provide services such as software and web development, open source support and consulting, and hosting services.
As an accessibility specialist, I test and audit websites developed by Catalyst for its clients. I identify the accessibility issues in the websites and provide recommendations for each issue. I also promote open source assistive technologies and deal with any activity related to accessibility.
I’ve been with Catalyst for one month now, and I feel fortunate that through my new work, I’ve already learned a number of important lessons as an accessibility advocate.
Using Assistive Technology in Accessibility Audits
Since Catalyst is an open source company, we decided that it would be good for me to use the NVDA screen reader in doing my accessibility audits. NVDA, or Non Visual Desktop Access, is a free and open source screen reader. A screen reader is a type of assistive technology that reads the text currently highlighted on the screen.
Although I’ve used NVDA many times before, I didn’t actually use it in my accessibility audits. I used another commercial screen reader. I saw this situation as a challenge and even as a concern. At first I thought that using NVDA, I wouldn’t be able to conduct thorough accessibility testing and audits. This is because I was used to using the other commercial screen reader.
Being the accessibility trooper that I am, I continued using NVDA. There were times when I needed to learn its more advanced features which I previously wasn’t aware of. And with time and countless hours of work, I saw that I could do accessibility testing as thoroughly and efficiently with NVDA as I did with the commercial screen reader.
So this is the first thing I’ve learned. My work doesn’t depend on the tool or technology that I use. What’s important is the time and effort I put in understanding the innate accessibility of the websites and the overall process of providing recommendations to address the issues I would find.
Creating Clearer Accessibility Reports
When I would write my accessibility reports, I would normally state the issue and follow it up with a recommendation. Basically my reports would consist of a list of issues juxtaposed with recommendations. Sounds good, right? Well…
One hazy midnight, I was browsing web pages and reading accessibility reports done by other persons. And that ordinary browsing session turned out to be a truly important experience. Thanks to the accessibility advocates who wrote those reports, I realized the value of one small but very helpful detail.
Second lesson learned: When writing accessibility reports, tell the readers where you found the issues. I think this is how an accessibility report should be in the first place. It would help web developers a lot if in addition to telling them about the issues, you would also tell them exactly where you found the said issues. A good way to do this is to state a particular web page and under it, state the issues you found and your recommendations.
Going Beyond the Guidelines
I used to think that studying the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) was enough for me to know what accessible online content should be. But in time, I learned that WCAG 2.0 should only be the foundation of one’s knowledge in accessibility. Web accessibility is an immensely huge field, and with the creation and development of new technologies, accessibility can only become more huge in the coming years.
I still believe though that WCAG 2.0 is the most important document when it comes to accessibility. However, I also think that it is crucial to learn about the other accessibility techniques, issues, and principles out there. Also, I have talked to several colleagues at the office about accessibility, and they’ve asked interesting questions that aren’t really addressed by WCAG.
All these things motivated me to learn and learn more. I do this by constantly reading about new developments on accessibility. I devote one to two hours everyday reading articles with the accessibility hashtag (#Accessibility) on Twitter. I also recommend joining accessibility mailing lists. WebAIM’s Web Accessibility E-mail Discussion List is an excellent example of these online communities.
I’ll end this by thanking you, my fellow accessibility troopers, for letting me share the lessons I’ve learned recently. Let’s carry on and help each other in supporting a more accessible Internet. I’d love to learn with you and learn from you!