Accessibility issues


I am a blind Java developper and try to use Sonar Qube.
But is not easy because the page of the server are not compliance wit WCGA (Web ). Contente Guideline Accessibility
So I a prefer to used the Eclipseplugin.

For examp(…)le there are no area to split the content,

Header informations Main content of the ppage. menu item ....

 <footer role="contentinfo">
 Footer informations

An I would lie to know if there is a plugin to check accessibility compliance



Hello @CoderInTheDark

First of all, I’m really sorry for your inconvenience with SonarQube. Unfortunately, SonarQube was not designed in an inclusive way, and we have a lot of accessibility debt that we are aware of.

For 2019, the User Experience team at SonarSource committed to make our software more accessible to visually impaired users. We will start by addressing the needs of partially sighted people, like colorblind users, by enhancing everything relating to contrasts, color accessibility, and typography accessibility.

Then, our next challenge might be to make SonarQube accessible to blind users. We are eager to make it possible to use assistive technology like screen readers. We currently acknowledge that our markup architecture is not ready for this, and we sincerely apologize for it. We will probably need to do research and trainings in the future to become really good at handling this.

In the meantime, if you know of good resources, or quick wins that our front-end team can implement that would make your life easier, I encourage you to share it with us.

We consider having blind community members to be a huge plus to help us in this journey. I will follow-up with you once we get started on this topic, and I hope we can keep in touch for the future developments of an accessible SonarQube.

Thanks a lot for your feedback


Hi @CoderInTheDark,

To complete the answer from Laura, as Analyzers Product Manager, I can say this is part of our plans for 2019 to have more rules in SonarHTML to make web content more accessible. It means we will implement rules that will help us internally to make SonarQube better on that field but also help other developers make their products better. So your need of a “plugin to check accessibility compliance” should be cover sooner or later by SonarHTML.

In addition to, do you have any other guidelines that we should study that will help blind developers to have a better user experience ?


1 Like


I wrote this article with a freind, but it is in french

I also wrote an article about Swing

Today I am too busy to give you more information.

An other guideline from W3C is ARIA(Accessible Rich Internet Application).

The use of parametter of role to give a purpose to tag, is very
important for tag like span or div which have no purpose, or when the
tag have been changed of purpose.


Hi @CoderInTheDark,

Thank you for these references. We have many native french speakers at SonarSource so we will gladly read your articles.



Below I past a draft of the planed next of the previous article, wich
gives HTML tips to accessibility

_Comment écrire du HTML accessible._

*Dans ce document nous expliquerons essentiellement comment écrire du
HTML accessible. D’une manière générale il convient d’utiliser le HTML
de façon sémantique et non visuelle. C’est-à-dire qu’une balise doit
être utilisée pour son rôle et non pour son rendu à l’écran. Car les
lecteurs d’écran s’appuie sur le rôle ou la fonction d’une balise HTML,
pour retourner les informations aux utilisateurs non-voyants. *Si l’on
souhaite agir sur la présentation il convient d’utiliser les propriétés

On peut s’appuyer sur la norme ARIA(Accessible Rich Internet
Application)du W3C et HTML5, qui sont des formidables avancées en
matière d’accessibilité.

Afin de restituer l’information à l’utilisateur le lecteur d’écran,
crée une copie de la page, qui s’appuie sur le code HTML, pour créer une
version accessible à plat.

La page HTML

Lorsque l’internaute non-voyant arrive sur une page, un certain nombre
d’informations lui sont annoncées :

Liste de 3 éléments


Just a follow-up on this thread for our community members concerned with accessibility.

With the precious help of @CoderInTheDark the UX and Front-end teams at SonarSource have identified a few improvements that can make SonarQube and SonarCloud more accessible to visually impaired people. Here is a list of tickets we intend to fix in the upcoming weeks:

SONAR-11751 Use semantic elements for the app header, footer etc.

SONAR-11749 Add “Jump to content” link for assistive technology users

SONAR-11748 Headings hierarchy should be semantically correct

SONAR-11688 “Help” link in header is not accessible

SONAR-11685 “Add project to favorites” link is not accessible

SONAR-11684 “Set home” link is not accessible

SONAR-11759 Make Measures graphs accessible

SONAR-11750 Add visible “focus” state on links for keyboard navigation

We’re still in touch with @CoderInTheDark to make things even better in the future. I’d like to take this opportunity to thank him publicly for the time he spent with us, this was truly insightful. We’re grateful for having a strong community willing to help us make things better :smiling_face_with_three_hearts:



Voici un lien ver le GitHub de l’article.

Je n’ai pas mis d’images, car je suis toujours à la recherche de graphique libres de droits.

Si vous voulez faire des retours


Je me pose des questions dur la façon dont vous pouvez travailler sur l’accessibilité.
C’est le monde à l’envers,. :smiley:
comment faites vous pour constater les problèmes d’accessibilité ?
Seulement avec les remontées d’informations ?
Dans ce cas vous devez faire une confiance aveugle à un message.

Utilisez vous un lecteur d’écran ? (NVDA, Jaws, Narateur, VoiceOver, Orca, ZoomText)
Utiliser vous des outils tiers ?
Les validateurs W3C donnent des indications.

Si vous utilisez un lecteur d’écrans.
Indiquer les raccourçis claviers dans l’articles peut-il vous aider dans la démarche de mise en accesibilité ?

Ou utilisez vous un outil de testes d’interfaces ?

Bonjour @CoderInTheDark

Yes, indeed, we started using our own product using a screen reader (Voice Over on Mac, mainly). It’s a great way to feel the areas where there’s a lot of friction (of course, as we’re not power users of VO, we might feel more friction than a seasoned user would – still, it’s a great exercice). This method allowed us to find many issues, some of which @Laura already listed. A full list of open accessibility issues/tasks can be found here.

Not all 3rd party tools are helpful to us, as the UI is basically a SPA (Single Page App), which means parts of the DOM are being re-rendered all the time. Some tools cannot handle this scenario. Others fail to find relevant pointers. All in all, we stick to using VO for now.

A post was split to a new topic: Add support for “Accessibility Conformance Testing (ACT) Rules Format 1.0"”