Firefox Developer Tools: Accessibility inspector | Hacker News Reader

Firefox Developer Tools: Accessibility inspector

developer.mozilla.org

441 pointsteamhappy55 comments

I hope this means the developer tools themselves will actually become accessible. As a blind web developer running Linux and Orca, bunches of things have been broken for a very long time, to the point where I'm considering switching to ChromeOS and running Linux in chroots/containers just to get a better set of web development tools. I'm glad that they're empowering developers to create accessible websites, but if blind/disabled developers were empowered to develop on equal footing, then that'd be another way to achieve the same goal.

As one example, I can't navigate the network inspector via keyboard in any meaningful way. Firebug used to have this nailed, to the point where you could even enable an accessibility mode (though arguably accessibility mode should have just been the only mode.) And yes, I'd happily file issues for this and half a dozen other things, but at some point I actually have to do my job, and in this case that might mean jumping ship to a browser that seems more accessible.

I think this point is extremely important. Often in the rush to "help" those who need improved accessibility we deny the very people we're trying to "help" the ability to fix things for themselves. (And they often do a better job of it too, since they're invested in a good outcome.)

I'm not visually impaired, but have run into the exact same issue of missing keyboard shortcuts for dev tools. There are some, but they seem pretty random. I thought devs would work more with shortcuts, but apparently not.

However, the network inspector in Firefox opens with Ctrl+Shift+E for me (Ubuntu with Unity).

Right, but opening from the keyboard is only a tiny fraction of what is needed. If I tab around on the display, I get a bunch of buttons that are likely column headers (I.e. "Status", "Transferred", etc.) but I never reach a list of actual requests through which I can arrow. I press Space on a button labeled "Start performance analysis" which immediately plunks focus into a text field from which I can't seem to escape. The entire developer tools interface is littered with these sorts of inconsistencies.

The HTML inspector is similar. I can pull up a tree of elements, but sometimes I can expand tree levels from the keyboard and sometimes I can't. I've taken to using the context menu to copy an element's inner HTML into a text editor, then inspecting it that way. Often, clicking Inspect Element from the context menu doesn't open the inspector with keyboard focus on the element I'm inspecting, either, which is a massive pain when I'm trying to tell a developer what is needed to make a site accessible. So, IOW, I can't even file actionable bug reports for web apps without putting forth lots of effort to even identify the element that is at fault.

Unfortunately, we live in a highly competitive/growth demanding times where companies chose to invest resources only on areas where they see good returns. This means that for-profit companies, like google, in long run would do far less than non-profit companies, like firefox,for special need audience.

Wasn't their comment saying that just the opposite was happening? That for-profit Google was better at this than non-profit Mozilla?

For-profit companies can also make a profit off a special need audience, if not directly then through good PR and not getting sued. So I'm not sure that Firefox will really have better accessibility in the long run.

Why is that unfortunate? If a company lack financial incentive to build something, means not many people want it, or the little that do don't want it enough

Or the ones that do want it enough don't have the means and the tools to de-marginalize themselves.

In this caae, I hope you're seeing the (sad and obvious) irony.

Even if all disabled people would have been poor, if there was enough of them, then relevant solutions would have emerged (similar to how cheap food came to be).

Disablities are unfortunate and sometimes sad. However, the way the market works is not. There are limited resources, and they are being distributed where the demand is highest.

Apple spent plenty of years doing what they felt was right, and not chase the highest demand.

On that example alone, I feel you're being short sighted.

Put another way, you're under the impression this is about people with special needs. Not at all. This is about people with special needs AND the people who believe they deserve the same "fair chance" the rest of us get. Not all of use are self-absorbed.

p.s. re: "similar to how cheap food came to be"

Seeing how this got us obesity and all the diseases that go with it, I'm not so sure you're model / mindset is the one that's ideal. Perhaps it's time to think more holistically?

Documentation, too. Most of MDN, ironically including this article, violates Web Content Accessibility Guidelines.

Marco Zehe is an Accessibility QA Engineer at Mozilla, he is blind, and he writes on his own site. Two years ago, he wrote a post, "The Firefox developer tools Inspector Panel is becoming accessible" [0]. I don't know how things have progressed since then and I wonder if there are problems particular to Firefox on Linux and Orca, as opposed to other combinations like Firefox for Windows with JAWS or NVDA.

[0] https://www.marcozehe.de/2016/05/24/the-firefox-developer-to...

As a front-end developer, accessibility has always been a way for me to describe to non-technical people what I actually do for a living.

Saying: "I build web applications" means nothing to them, and saying "I create website" makes you look like a wizard doing some black magic.

But saying "my job is to make websites accessible to everyone: we are used to use a screen and a mouse, but what if you are blind or deaf? Those people should not be allowed to go on any website? My role is to make those people able to browse the web, as you and me" give them an example of what kind of problems you actually solve as a web developer.

That's a pretty good way of communicating. I need to start changing "I write web servers" to "I make sure our customers, who are frequently in the middle of nowhere, can interact with the services we offer."

But those two statements seem to me to be very different. The first would make you a web backend developer and the other more of a network engineer or sysadmin. I know this probably isn't too different for many people, but those people won't probably be able to imagine a specific job if given either description.

I don't want to be just negative, so I'd like to suggest an alternative: "I make parts of computer programs, like <names of well-known products that are similar to ones you make>". This will be easily understandable to everyone who knows what computer programs are and also won't be misleading. You could also add "for the internet" somewhere if that part is important.

> Saying: "I build web applications" means nothing to them, and saying "I create website" makes you look like a wizard doing some black magic.

Who are these people? When people ask what I do I just tell them "I'm a developer; I make websites" and they understand what I do enough to move the conversation forward. Is there other context I'm missing?

There's a difference between informing someone of your job title (serviceable smalltalk) and actually telling them what you do (likely reserved for a conversation with someone who's demonstrated some interest)

In France, roughly 12% of people don't use the Internet - https://www.arcep.fr/uploads/tx_gspublication/State-Of-Inter...

In Indonesia, millions of people say that they don't use the Internet - but they do use Facebook - https://qz.com/333313/milliions-of-facebook-users-have-no-id...

For all of us, it's worth stepping out of our bubble to see how other people perceive what we take for granted.

Those are really interesting statistics. Would be a good idea to look those up before traveling on business

Who are these people?

The other 98% of the world.

Context probably matters. Those "in the working world" are likely somehow familiar; others perhaps far less so.

While the roles certainly overlap, frontend dev and accessiblity for me have become separate roles. The level of knowledge and expertise just too much in each.

If you're able to pull it off, that's impressive.

For every website a client has asked me to check SEO reports and the like, I get 0 requests to check accessibility or any mention of it. I do my best to make what I build accessible with the time I have, but clients (and many employers) seem blind to it. Has anyone had any success with getting accessibility taken more seriously in these contexts?

Show them that lawsuits are happening more and more due to precedent set in many states that ADA regulations for buildings and such also apply to websites.

https://www.forbes.com/sites/legalnewsline/2017/06/13/first-...

Nope. It is deeply misunderstood across the 'industry'. Blank stares ensue.

There is opportunity in this as SEO (a 'service' that can be sold) really depends on accessibility. I find people still concerned with 'keyword frequency' and whether they have their H1 tags in the right place when it comes to 'SEO'. Nobody is talking about making the web better for everyone (which includes the customers with no accessibility problems) and that being the central plank of better sales.

A further problem is that web 'design' agencies do not have the sales staff to sell accessibility. The pitch should not be that hard given that the baby boomer generation have all the money and need spectacles to read anything closer than arms-length away.

I also have yet to see anyone offering accessibility audit services where a genuine, registered partially sighted person does the auditing and testing. This could be end to end, i.e. ordering the product and returning it, with all emails checked along the way, complete with physical packaging.

We assume 'we know best' and that we know what a screen-reader user would want rather than reach out to anyone who is practically blind and ask them what they think. Patronising!!!

Those services definitely exist. I’ve used the DAC[1] in Cardiff before for indepth review from expert users of assistive tech, but I’ve also taken part in standard user research with people with accessibility needs (ranging from blindness to motor problems to severe dyslexia). One thing to bear in mind when doing user research like that is that bringing people into your lab won’t work: people who use assistive tech setups tend to customise them to fit their needs, so you need to get out and observe ‘in the field’ if possible.

[1] http://digitalaccessibilitycentre.org/

The http://digitalaccessibilitycentre.org/ website is awful. Efforts like this give accessibility a bad name.

Accessibility isn't about designing websites that are exclusively for special needs people. It is about making websites work for everyone, whatever device they are on. Part of that ethos is sticking to convention.

So what is so awful?

The navigation is awful. It changes from the homepage to one of the other pages.

Their use of mini-font sizes is also a bit silly.

Even the URL structure is a bit silly, nobody needs to have index.php in a URL to make it mysteriously more accessible.

Their headings have line heights that mean 2-line headings are mangled together.

If you run a outline on their pages the content does not reflect what is shown.

I would be embarrassed if I worked with these so-called accessibility experts, their efforts sideline what accessibility is about. Cringeworthy and awful!!!

No comment on their site, but their employees helped me discover and resolve problems I never would have, for example a breaking problem in Windows 10 high contrast mode, or a problem with a specific version of Dragon NaturallySpeaking that was earlier than the one I had been testing on.

Accessibility is never a problem until it is. And it will be a problem - eventually, every single time. My last two companies, i pleaded with them to think about it before it became a problem. They ignored me, and two years later - in both cases, I kid you not, we got named in ADA action and lost tons of money/time trying to respond. You don't get to choose whether or not you get sued under ADA, you just will as a matter of course (the bigger you are, the sooner). What you can choose to do is be thoughtful about it early, and see it as an opportunity to make your site better for everyone.. the thing is a lot of the a11y stuff you need to do is good for every user. ... or you can wait until you get sued and have your operations grind to an agonizing halt as you try to figure out how to undo the mess of years of bad coding in a massive whole-site rewrite.

Bundle it with localization/I18N -- most people understand the need for that. Also mention "screen readers" -- something tangible.

I find it really depends on where you live or who you're working for. Here in Canada (Ontario specifically), it's a pretty big deal given that some organizations have to hit accessibility requirements on their sites if they have certain characteristics (number of employees etc.).

It's led to a good percentage of the work done here (both in traditional CMS implementations to custom applications) require accessibility not as an after thought, but baked in by default.

Makes it better for everyone, but without a good handle on what it actually means, and ensuring that whatever toolsets you're using (CMS, JS/CSS/backend framework, library etc.) also provide the necessary tooling as well, it can make projects run over time/budget.

Factor that in first, learn the tech/tools, and it doesn't have to be that dramatic. I'm assuming that common accessibility on the web/mobile will be expected nearly everywhere "soon".

Can you recommend any resources to help me learn best practices in this area?

* Target low hanging fruit using browser extensions and CI tools like:

http://khan.github.io/tota11y/

https://chrome.google.com/webstore/detail/axe/lhdoppojpmngad...

https://github.com/dequelabs/axe-webdriverjs

* Try using your site, app, document, whatever with a screen reader like NVDA or VoiceOver

https://webaim.org/articles/nvda/

* Check out Google's A11ycasts (also features NVDA):

https://www.youtube.com/watch?v=HtTyRajRuyY&index=30&list=PL...

* If you don't have a lot of time:

https://wiki.fluidproject.org/display/fluid/Quick-and-Dirty+...

* If you have more time:

https://wiki.fluidproject.org/display/fluid/Making+an+Inclus...

Thank you very much!

As the saying goes, your most important website visitor — the google search bot — is blind.

> but clients (and many employers) seem blind to it.

I see what you did there

Make them actually blind to it! Change the color palette to mimic various color blindnesses. wire up a spastic mouse, make them use an "approximate keyboard" with no markings.

> seem blind to it

I couldn't help to notice the involuntary pun. What you say is sadly true, and it is a sort of cognitive blindness.

I use the Accessibility Inspector in Chrome's devtools. But in both the cases of Firefox and Chrome, it should be remembered that the Accessibility Inspector is only a partial view into accessibility issues, and that better extensions exist to show you a broader picture.

See this article for suggestions in other better tools and techniques:

https://www.24a11y.com/2017/accessibility-testing-tools-desk...

I agree with ndarilek's comment. When the Firebug team started making firebug.next, there were huge problems with the inbuilt dev-tools. They then decided to merge the two projects and stopped developing Firebug. I had expressed my concerns to them after trying the beta for a long time. The team was very receptive of the comments, but sadly not much was implemented until I stopped using FF as my main browser. Even to this date, the Firefox Devtools are nowhere near Chrome's. Yes, there are some very useful features added in Firefox's Devtools but the performance is very poor. Especially the Scripting tab. Try setting a breakpoint in a half-decent webapp - the whole browser(!) hangs for atleast 10 minutes, sometimes forever. There were problems with displaying raw JSON response in the network tab too for a long time - Firebug had the funtionality, so was shocking to see FF drop it in favour of a very clumsy and inaccessible tree view. Then, when FF Quantumcame, I flocked back to FF thinking the devtools would be fixed too. Nope. I have been a long time FF user (I think since v1.5, Netscape before that), and would very much like to use FF as my main browser. But as a web developer, it's impossible to use it. The sheer number of hours wasted just trying to keep my browser to not hang trumps my fanboyism. There is nothing better than what Chrome offers in this area.

I use Firefox’s dev tools for my work on FastMail and Topicbox (the other guy who does the most frontend work uses Chrome). Firefox’s debugger is definitely painfully slow when paused and stepping, but I can’t reproduce what you say about full-browser hangs. Setting a breakpoint completes within a few hundred milliseconds (most of which is just rendering).

The fancy JSON thing: if you collapse the “JSON” expander you’ll see another, “Response payload”, which shows it as text. (If JSON is expanded, Response payload may not expand properly; that’s a bug. I haven’t reported it despite knowing about it for a while.)

Firefox has been my primary browser since 0.93, save for a year or so on Chrome when I had to run it from a USB stick and Firefox got just too slow there. Nightly has been my daily driver for most of this decade.

The JSON thing they have fixed - I think I didn't make it explicitly clear in my comment. But it was that tree view for quite some time after the new devtools revamp.

About the full browser hangs - maybe it was my own system, but I usually had Slack and Gmail open. And those tabs already ate a lot of RAM, making FF sluggish. Opening the scripting tab on my own dev site used to make the browser just get stuck. Devtools didn't use to respond either, but clicking on the close button sometimes worked, so I had to hope that I could click on the cross button without triggering the dreaded "This app has stopped responding" dialog.

Great to see browsers adding accessibility in their devtools since a few months!

One thing I don't understand here: why is the Accessibility tab not shown by default? Accessibility is something lots of developers don't even know about. I'm sure having the tab visible by default would help greatly in making developers more aware of it.

Just guessing here, but if this feature is new, you'd want to show it to people who know what they're doing and look for it actively.

This way you can get feedback from experts in the field to refine the interface and features. Once you have a solid viable product, you can show it to the rest of the world and see how well it serves the needs of people less in the know, without frightening them with a half-baked tool.

No, it slows the performance of dev tools and increases the memory usage when turned on. It is addressed in the article, as stated by someone else.

Having the tab shown and having the accessibility tool working and consuming resource seems to be two different things.

This seems like a good explaination!

> why is the Accessibility tab not shown by default?

The article has this to say: "This is because the accessibility engine runs in the background when the accessibility features are turned on. While it’s running, it slows performance and takes up memory; therefore it interferes with the metrics from other panels such as Memory and Performance as well as overall browser performance. For this reason you should keep it turned off when you aren't specifically using it."

From what I understood, having the engine running (and using resources in the background) is different from having the accessibility tab shown.

The contents of the tab come from the accessibility engine though, so running the engine (and using those resources) is a prerequisite for showing the tab.

The network tab also doesn't show anything until you select it and make some new requests. The accessibility tab is handled the same way, with a short notice about the performance implications of enabling it. So that really isn't a reason to completely hide it.

No, the tab prompts you to turn on accessibility features.

Good timing. I'm currently working on an existing app that is targeted specifically at those with accessibility issues as part of a larger service offering. More so towards those with hearing issues.

This is a good first step, I have been using the WAVE accessibility plug in for Firefox to identify missed issues in my first run through of the app.

Luckily, we have an employee with a visual impairment that we can utilize for real world testing of the app.

This really is its own specialty.

This is great news. Just making it easier for developers to see the impact of small things without having to go look for tools to do it is huge in this area.

Reply on news.ycombinator.com