The State of Accessibility in PHP Tools

Share this article

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!

Stock Image of Braille Code

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.


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

What are the key features to look for in a PHP accessibility tool?

When choosing a PHP accessibility tool, there are several key features to consider. Firstly, the tool should be able to identify and report accessibility issues in your code. This includes issues related to color contrast, keyboard accessibility, and screen reader compatibility. Secondly, the tool should provide clear and actionable recommendations on how to fix these issues. Thirdly, the tool should support automated testing, allowing you to integrate accessibility checks into your development workflow. Lastly, the tool should be easy to use and have good documentation and support.

How can PHP accessibility tools improve the user experience?

PHP accessibility tools can significantly improve the user experience by ensuring that your website or application is accessible to all users, including those with disabilities. These tools can help identify and fix issues that may prevent users with visual, auditory, motor, or cognitive disabilities from using your site effectively. By improving accessibility, you can reach a wider audience, improve user satisfaction, and potentially increase conversions and sales.

Are there any free PHP accessibility tools available?

Yes, there are several free PHP accessibility tools available. These include tools like WAVE, aXe, and Pa11y. These tools can identify accessibility issues in your code and provide recommendations on how to fix them. However, keep in mind that while these tools can be very helpful, they are not a substitute for manual testing and user feedback.

How do PHP accessibility tools integrate with development workflows?

PHP accessibility tools can be integrated into your development workflow in several ways. Some tools provide plugins or extensions for popular code editors and IDEs, allowing you to check for accessibility issues as you write code. Other tools support continuous integration, allowing you to run accessibility checks as part of your build process. This can help catch accessibility issues early, before they make it into production.

Can PHP accessibility tools help with SEO?

Yes, improving accessibility can also have benefits for SEO. Many of the practices that improve accessibility, such as using semantic HTML, providing alt text for images, and ensuring good color contrast, can also improve your site’s visibility to search engines. Additionally, search engines may favor sites that provide a good user experience, including accessibility.

What are some common accessibility issues that PHP tools can identify?

PHP accessibility tools can identify a wide range of accessibility issues. These include issues related to color contrast, keyboard accessibility, form labels, image alt text, and ARIA roles and properties. They can also identify issues related to the use of JavaScript and dynamic content, which can sometimes create barriers for users with disabilities.

How often should I run accessibility checks on my PHP code?

It’s a good practice to run accessibility checks on your PHP code regularly. This could be as part of your development workflow, where you run checks every time you make changes to your code, or it could be on a regular schedule, such as once a week or once a month. Regular checks can help catch accessibility issues early and ensure that your site remains accessible as it evolves.

Can PHP accessibility tools check for compliance with specific accessibility standards?

Yes, many PHP accessibility tools can check for compliance with specific accessibility standards, such as WCAG 2.0 or Section 508. These tools can provide a detailed report of any issues that may prevent your site from meeting these standards, along with recommendations on how to fix them.

What are some limitations of PHP accessibility tools?

While PHP accessibility tools can be very helpful, they do have some limitations. For example, they can’t fully replicate the experience of a user with a disability, and they may not catch all accessibility issues. Additionally, these tools can sometimes produce false positives or negatives. Therefore, while these tools are a valuable part of an accessibility strategy, they should be used in conjunction with manual testing and user feedback.

How can I learn more about PHP accessibility?

There are many resources available to learn more about PHP accessibility. These include online tutorials, blogs, and forums, as well as books and courses. Additionally, many PHP accessibility tools provide documentation and tutorials to help you get started.

Parham DoustdarParham Doustdar
View Author

Parham Doustdar is an Iranian, completely blind developer who was born in February of 1990. He specializes in writing clean, maintainable back-end code with a high test coverage, and believes that code must be readable with the smallest amount of effort. He has been a fan of writing for a long time, but has found himself worthy of sharing knowledge only recently. He enjoys being part of a larger community, and urges everyone to message or follow him on any social network, or just simply to email him!

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week