The State of Accessibility in PHP Tools

Usually when I tell people that I’m blind, many people ask me how I can use the computer. “Is someone reading you my messages?” I remember someone asking. Many people imagine that I have this super-nifty speech recognition software that I can just talk to, and it would do anything, even write code. Imagine dictating code to a speech recognition system!

I gave an answer on Quora, to someone who had asked How does a visually impaired computer programmer do programming? I recommend you go through that answer to have a better context on what I’ll be talking about in this post. As is my habit, though, I’ll still point out the important bits here, so if you don’t feel like clicking on that link, don’t worry!

Before I get to the comparison, allow me to give you a few facts so that we are all on the same page. Feel free to skip forward if you already know these points, but I’ve found that a lot of people don’t, and I’m going to start with those.

How do the blind use computers?

They use screen readers. As the name implies, these applications read the screen through synthesized speech, and they also have an optional Braille output through a Braille display. Both of these options (speech and Braille) have to go through the screen reader, though, so if the screen reader can’t see the content, it can’t display it through either of these outputs.

How do you type? How do you use the mouse?

The answer to both these questions is, “through the keyboard”. Our screen readers have very specialized keystrokes that allow us to move the mouse, click, hover on an item, and jump around in web documents (by links, h1-6 headings, lists and list items, form fields and many more).

Sounds very powerful! Does this mean there’s nothing you can’t do with a computer?

I wish. No.

Why? The reasons, as in almost everything else, range from irresponsible people to the lack of time and information. After all, the disabled are but a minority, and their voice is not as loud as, say, the people who call for the native support of the latest shiny PHP framework. The problem is that screen readers use low-level APIs to give them information on the window. They ask the browser, or in terms of desktop applications, the operating system, to tell them what kind of control or window they are dealing with. Is this item that has just gained focus a text box, or is it a check box? What is its value, and its label? What is its state (i.e. is it checked or unchecked, selected or unselected)?

A Brief Detour to the World of Web Applications

This kind of API was simply not available for the web until the last few years when the WAI-ARIA was published by the World Wide Web Consortium (W3C) and later on became a standard recommendation on march of 2014. Before that time, there was no information on how to make accessible, custom client-side elements, or client-side updates.

For example, a lot of people use a span element to create a custom button. Screen readers recognize this element as static text, as it is not a button, or an input of type submit. However, for someone sighted, it’s styled like a button, it acts like a button, and it even stays down like a button (for toggle buttons).

What web developers can do at this point is to explicitly mention that a span is a button, by using the button role. The code is so simple, many people can’t believe it:

<span class="button danger" role="button">Self-destruct!</span>

Done. Through this cosmetic change that wouldn’t take more than ten seconds (I’m counting eight seconds for hunting down the button), you’ve made your application easier to use for thousands. Isn’t it worth the effort?

Note: If you want to know more about web accessibility (I hope that you do), you can get a very in-depth coverage of many topics at the WebAIM articles page.

The State of Accessibility in IDEs

With more than one billion disabled people in the world, and most of them unemployed, those with disabilities don’t need any favors or for people to pity them – they just need a level playing field, which can be created by making applications just as accessible to them as others. This holds especially true for applications that are tied to employment. Tools such as IDEs may not be essential for everyone, but they certainly increase the productivity of many people, and when you are disabled, you need to be fast. You need to be a great learner and doer, or your existence for a company serves no purpose and you’re out of your job. I’ve heard many people complain about the unfairness of this approach, but I’m sure we all can agree that no one has the time to babysit, especially not in a technical environment.

With that said, let’s look at the most-favored tools of our own industry one at a time. I will be referring to the survey done by SitePoint for the Best PHP IDE in 2014, and the question we will be seeking to answer is: how friendly is web development for the people who are blind and thinking of using an IDE to speed up their learning process, workflow, or both?

I will give each IDE a score of between one to four for the following points:

• Essential features: is the editor accessible? What about the menus and the title bar?
• Assistance features: how much can a blind developer be assisted by this IDE while coding? Are code completion, PHP documentation, and PHPDoc pop-ups accessible?
• Supplementary features: What about the non-essential features, like integration with Git, the console, debugging, and so on?
• Community engagement: have they responded to issues/comments?

Number One: PHPStorm

We all know that PHPStorm is a really good IDE. It has near-instant support for new frameworks and technologies such as Laravel and HHVM, it has very nifty features for renaming, moving, and refactoring that take care of a lot of nitty-gritty details like changing namespaces, and its attempts at guessing variable types are mostly successful.

In terms of accessibility, though, I’m afraid PHPStorm gets a score of – wait for it – zero!

Yes! The main window is not accessible, and when this feature is not available, neither are the others. If you look at the accessibility issue, you will see that their team hasn’t responded with any updates to this issue at all. I urge you to upvote that issue, so that it may be noticed by their team.

Number Two: SublimeText

Ah, the bliss of having a multi-platform, lightning-fast lightweight IDE that can be customized by using a large number of plugins. One of the people I was interviewing for my current job would even go so far as to say, “everyone in your company must use SublimeText.”

And yet, this bliss is also denied to the prospective PHP programmer. This IDE also gets a zero, because nothing in it is accessible to screen readers, and the UserEcho thread for accessibility hasn’t gotten any responses from their core team.

Number Three: NetBeans

NetBeans is famous for its cool snippet generation capabilities, and its “quick-fix” functionality which does a lot of things for you automatically. The bug reporting feature is also very cool.

Accessibility wise, NetBeans is a bit better. I can navigate in the code, although with a lot of extra keystrokes as it keeps moving my screen reader’s focus to the Navigator. However, I have been hearing good things about the efforts of the Quorum project and apparently, NetBeans is going to have extra accessibility features soon.

Number Four: Eclipse-based IDEs (Zend Studio, Eclipse PDT)

I’ve always heard that Zend Studio and Eclipse PDT are nowhere as good as PHPStorm. At work, all my colleagues use PHPStorm. While I agree with their assessment, Zend Studio has something for me that PHPStorm doesn’t have: it’s accessible.

The code editor window and all other windows are accessible. The autocompletions or code assist suggestions are accessible, and so is documentation. Even the annotations (for example, why Zend has drawn a red line under your line of code) are accessible. Zend Studio and Eclipse PDT are both the most accessible IDEs I have ever used.

To be fair, though, Zend Studio and Eclipse PDT both owe their accessibility to the Eclipse team. Eclipse has been accessible for years, and they take accessibility very seriously. However, since we’re rating accessibility here and not development teams, Zend Studio and Eclipse PDT get a resounding four!

Eclipse even has a page, Accessibility Features for Eclipse that gives blind and visually impaired users more tips on how to use Eclipse and Eclipse-based IDEs.

Number Five: Notepad++

I consider Notepad++ an editor, and not an IDE. It is nowhere as customizable as SublimeText, and nowhere as big as PHPStorm and Zend Studio in terms of memory and CPU consumption. It’s awesome for when you have to edit a piece of code and you know perfectly well the functions you will be calling, or the values you will be setting.

The Notepad++ windows and options are all accessible – that is, the essential features. The non-essential features aren’t accessible, though. Things such as autocompletions and errors are not announced by screen readers.

Over the years, though, Notepad++ has become more accessible in overall usage. There have been responses and cosmetic changes, but when you compare their community engagement with the top two IDEs above, they have been a lot more engaged. I give this editor a two – one for essential features, and one for community engagement.

Conclusion

The PHP landscape is not bright and sunny in terms of accessibility. Whereas the sighted have the option of choosing between free and paid IDEs, the best IDE in terms of accessibility are Eclipse-based editors. While this is much better than nothing, it leaves a lot to be desired. Technology is for everyone, and we should strive to make it so.

Frequently Asked Questions (FAQs) on PHP Accessibility Tools