We appreciate the feedback regarding Jira accessibility and recognize this issue has been open for a very long time.

As part of our new Accessibility program, we are assessing Jira's current level of accessibility and will use this information to inform our investments. 

I have cataracts and have great difficulty seeing the light gray on white text.

I would really appreciate it if Jira and Confluence offered a dark or high contrast theme.

This issue was opened in 2004, and still "GATHERING INTEREST"? Well I hope this comment pushes the issue into "WE'RE WORKING ON IT".

For a product that costs so much and keeps "Improving" the interface, it is disappointing that accessibility has not been incorporated into these UI updates.

Can someone from Atlassian please comment on whether getting any work is being done on updated VPATs for Jira Cloud, JSD Cloud, and Confluence Cloud? I noticed in the server version of this request that work is being done. https://jira.atlassian.com/browse/JRASERVER-5574   Thank you!

atlassian.net/browse/HELP-5
after the main heading there is a row of links (edit, comment, ...) on the right edge are 3 icon links 1. share issue, 2. export issue, 3. 3 horizontal dots (More?)
none have a label that is readable with a screen reader. 1 and 2 have title attributes, but title is not read by screen readers. 3 has no title and no accessible label. 
note the three horizontal dots is used many places. all need a label
putting the title value as an aria-label attribute value would solve the problem on all 3 icons

Perhaps they will address it at the Atlassian Government Symposium, but I do not see it on the agenda.

+1 – I'm very interested in updates on this.

Sean Curtis,

I haven't seen an update here or on Twitter via Atlassianaccess in a year and a half.  It's important to note that Section 508 will use WCAG 2.0 effective 7/17/17.

Are there any updates?

Ok,, I think I created an issue, but I'm not sure that it was created as draft, or it was already published.

Thanks Dave Meyer.
Sean Curtis, it seems that we are using a server version of jira.

Carmen.TODORUT1268587102 could I ask whether you're using a Cloud or Server version of JIRA? We rolled out some improvements to that component a couple of months ago, and the improvements should be available in Cloud, and the latest 6.4/7 releases.

Carmen.TODORUT1268587102, since the list of epics is a JIRA Software feature, you should report it in the "JIRA Software (including JIRA Agile)" project here on jira.atlassian.com. The project key is GHS.

Thank you very much for your answer Dave Meyer.
I have another question...
When I create an issue in jira, I can't see the list of the epics, so it is very difficult to add an epic to an issue, using a screen reader. Where should I report this?
Thank you.

twillis352322601, you should create a support request with HipChat support, and they will create an issue with the development team on your behalf.

@Dave Meyer, where can I log issue for Hipchat?

Hi Carmen.TODORUT1268587102,

You should report accessibility bugs in the Zephyr add-on directly to Zephyr. Unfortunately, I was not able to find a public issue tracker for Zephyr, but their help center is at this URL: https://support.getzephyr.com/hc/en-us

Cheers,
Dave Meyer
Product Manager, JIRA Platform

Hello Sien Curtis,
I would like to ask you how I have to do if I'd want to create an issue about accessibility bugs in Zephyr. In fact, I'm a screen reader user (totally blind), and I'm working with Zephyr for doing tests. In the list of the tests it is not possible to execute a test.
Thanks alot for your help.

Hi caden – the VPAT reflects the latest release of JIRA. I'm sorry that our JIRA VPAT does not make this clear. I'll organise an update to the document to make this clearer.

You can try JIRA for free for 7 days. More info at https://www.atlassian.com/try

Two questions: I was looking at the JIRA VPAT at https://confluence.atlassian.com/display/ACCESSIBILITY/JIRA+VPAT+for+Section+508+compliance. What version of JIRA does this reflect? Also, is there a way for us to test a demo version of JIRA (and Confluence) for accessibility before we upgrade our system?

APark4 we can't provide timelines or roadmaps. However a rough version should be up soon. If you want updates, follow @atlassianaccess on Twitter. VPAT and other Accessibility-related news is posted on that account.

@scurtis, on 5/19/15 you stated the Confluence VPAT has been created but not completed. Can you provide a timeline for when this will become available?

cathleen.tracy there are some accessibility issues with dropdown menu navigation and some of the JavaScript-based select components. We're working hard to fix things, but it will take some time.

You can search for, or raise, accessibility-related bugs under the ACCESS project here: https://ecosystem.atlassian.net/issues/?jql=project%20%3D%20%22Atlassian%20Accessibility%22%20and%20resolution%20is%20empty

jlam1 the Confluence VPAT has been created but I'm still in the process of triaging (and labelling) the issues. Should be up soon. Do you need to know about any specific issues?

Has any VPAT been started in draft form for Confluence?

Add a comment

We are onboarding some new team members and a few are low vision and one is completely blind. Will they be able to use your software? We currently use JIRA, Stash, Confluence and Bamboo. Thanks!

Hi jhui1,

Our current focus is fixing the bugs which prevent people accessing core JIRA functionality; bugs that prevent navigating around the application, or raising/editing/commenting on issues.

We don't provide any timelines or roadmaps for our products, and I cannot give an estimation of when, or if, JIRA will achieve 100% section 508 compliance. I can say that we are continually improving JIRA's accessibility, driven by what is most valuable for people using assistive technology rather than ticking all the boxes for section 508 compliance.

We are after input on the main pain points with JIRA & assistive technology. Please raise accessibility bugs on our public issue tracker – https://jira.atlassian.com/.

Cheers,
Sean Curtis

We are currently supporting a federal agency's instance of JIRA and Confluence. The agency's 508 waiver for JIRA is coming up for renewal and review, and while the JIRA VPAT is helpful, we still need a timeline for attaining 508 compliance. We understand that given the size and scope of this task that the timeline may be approximate, but we do need something to ensure that we do not have to move away from JIRA only to find that it is 508 compliant 4 months later. Would someone from the Atlassian team be able to comment?

Thanks.

stephen.gramm@nasa.gov yup we will be tackling the accessibility of 3rd party plugins also. Issues we find will be raised as bugs (because they are) and should follow the same process for fixes.

(sorry for the delayed reply)

caden thanks for the prod. A fair bit has happened recently. We now have a VPAT for JIRA. It is only scoped to a few areas though (takes a while to audit an app as big as JIRA), but more audit work will be happening soon. The JIRA VPAT is linked from the new Accessibility page from the main site http://atlassian.com/accessibility – other product VPAT documents will be there soon also.

We've had a team fixing JIRA accessibility issues over the last month. I'm still gathering the exact numbers, but they fixed about 40 issues in the last month or so. We're still working on the blockers though (dropdown menus and combobox components) – the fixes for these should make their way to the Cloud version first, then either in a patch release for Server, or maybe in JIRA 7 (it depends on whether the accessibility fixes require a breaking change – which is likely as the entire markup pattern needs changing).

In summary: fixes are happening and audits are in progress (Confluence audit starts next week).

Any updates? We were just discussing today how we'd like to leverage the features of a newer version of Jira. How is the accessibilty effort progressing?

We have a recommendation for this topic. We should also expect the Atlassian "verified" plugins to be 100% compliant with Section 508. This may not impact everyone, but it is of great importance for our U.S. Government customer.

Hi a-twillis there is http://help.hipchat.com/forums/138883-suggestions-ideas/suggestions/3708250-voiceover-support and http://help.hipchat.com/forums/138883-suggestions-ideas/suggestions/3708343-support-wai-aria but they were both very simple in scope. I've raised http://help.hipchat.com/forums/138883-suggestions-ideas/suggestions/6567165-make-hipchat-accessible which should be a good starting point, please vote for it.

Our VPAT documents will link to all relevant bugs. I'm planning to use these VPAT documents as at-a-glance representations of known accessibility issues, a sort of entry point, if you will. I know HipChat has some extremely severe issues as far as accessibility is concerned. If you do want to raise some, can you make them as granular as possible – rather than just one huge "HipChat is inaccessible!" issue. Having granular issues makes it easier to identify and fix them.

Is there a similar card for HipChat accessibility that I can follow?
Thanks,
Toby

Hi a-twillis I agree with you on all points – you're preaching to the choir

We've had many passionate developers striving to ensure our products are accessible, however we dropped the ball on a couple of crucial things in the last year or two (dropdowns and autocomplete controls). We're working to fix them right now. Now that we have full-time resources allocated to accessibility we will be tackling all the little accessibility "paper cuts" which have crept into our products. The audits will be expanded to include other products and I've been educating staff on how to build things with accessibility baked in. It's part of the "definition of done" (like docs, automated tests, etc) for anything my team builds.

I'm extremely passionate about ensuring our products don't just tick some accessibility compliance boxes, but that they're a pleasure to use for everyone. I'll keep this issue updated with any further information.

Thanks for the update. I realize it takes time to implement changes in a large product. I can't help but notice that this card has been open for almost 10 years...
Jira and Confluence are certainly not the least accessible tools I've had to use; although Hipchat is among the worst products in my experience. I appreciate the work that has been done on Jira. Most of the remaining issues are exaserbated by messy programming and could be fixed with some relatively light work; like changing where content is injected into the dom or giving keyboard and mouse access to an existing component. ARIA attributes and refactoring aside, there are plenty of easy and immediate fixes that could have been implemented years before.
Based on a Jira customer's comments, Atlassian has lost business from customers working for the Federal Government due to the fact that the product does not meet Section 508 standards. That seems like bad business to me... Is Atlassian willing to sacrifice revenue and market share for the lack of accessibility?Like it or not, it's coming...just like ramps on buildings, applications will have to provide access to everyone. And, just like ramps in the built environment, electronic accessibility features will benefit everyone, including Atlassian.

Sorry for the silence regarding accessibility. I moved from the JIRA team to the team that works on our AUI frontend library at the start of this year (2014) as a dedicated resource assigned to improving the accessibility of all our products.

Currently we've been tackling the largest issue, our dropdown menus. We've spent a great deal of time getting them as accessible as possible. They should be hitting the products in the next few months (OnDemand users will see them first). We're also building a replacement for the single/multi select pickers.

We've contracted Deque to perform an initial audit of accessibility issues for our products – initially JIRA and Service Desk, but other products should follow soon after. We're raising them all as bugs and they'll go into our regular backlog of bugfix issues, which is awesome. Deque are also assisting us with the creation of VPAT and WCAG statements, which should help make it clear at a glance, just how accessible (or not) our products are.

I know it's been a long time coming. It won't happen overnight (JIRA and Confluence are HUGE), but the ball is rolling. I'll be posting links to our accessibility information, including the VPAT/WCAG statements to this thread once they're available (hopefully within the next week or two).

Any status update since Roy's 2013 update? I've changed employers twice since I first upvoted this issue. All three use Jira and Confluence-- obviously there are things we really like about them. However, it's been really disappointing to follow the progress of this issue and see no action being taken. My current employer can't upgrade and use new features we want because the accessibility has gotten worse instead of better. Any news?

I work for Expedia on the Client-side Engineering Team. I depend on a screen reader to access the computer and successfully fulfill my job responsibilities.
Unfortunately, Expedia relies heavily on Jira and HipChat, neither of which is accessible, the latter being completely impossible.
The level of access provided by Atlassian to Jira is reflective of systemic discrimination of people with disabilities. and the lack of response and marginalization of issues that are blockers for users with disabilities is indicative of Atlassian's unwillingness to comply with accepted web accessibility standards and in direct violation of the law.
Most of the fixes needed to provide W3C AA level access could be mitigated by following commonly accepted best practices for web development. Beyond that, the work required to negate the would-be remaining issues do not present an undue burden as defined by the ADA.
Further more, the ticket is filed as a "suggestion"; accessibility is not a suggestion, it's a requirement.

We will not be able to renew our JIRA license at our US Federal agency after this year because of the lack of progress on making JIRA compliant with 508 Accessibility requirements. We tested the JIRA UI and found 32 issues, all multiple instances of the same three issues:
1. Make sure users can skip repetitive navigation links.
2. There should be a non-empty title element in the head of the document.
3. Each form control should have associated text.
We can provide the test results with identification of the location of each problem found.
All this debate, and Atlassian can't just fix it? Come on guys, this ticket has been open for nine years; your customers are having to convert to other software. That's what we have to do now.

Jeff ( @jeff11 ) - I took a further look at AUI. I was pleased to see that some effort around accessibility is there, though the components still have issues as documented by Atlassian itself (e.g. https://developer.atlassian.com/display/AUI/Dropdown2#Dropdown2-Knownissues). One of issues that I bring up in the video (http://tiny.cc/jira508) is that the Version and Component multi-select pickers/dropdowns do not work with assistive technology, such as JAWS and VoiceOver. Unfortunately as far as I can tell those UI components have not yet been ported to AUI, thus I or anybody else cannot contribute a fix. I wish Roy a speedy journey to migrate Jira and Confluence to fully use AUI or at least implement a short-term for the multi-select picker.

Also, Benetech (http://benetech.org), a nonprofit software development organization, would be happy to collaborate with Atlassian in a ShipIt Day (http://www.atlassian.com/company/about/shipit) to stomp out these accessibility bugs. We are based in Palo Alto, so we would bring to the Atlassian SF office some of our blind QA engineers and developers and our JavaScript developers who are very familiar with developing complex yet accessible JavaScript UIs. Also since Benetech is a nonprofit focused on global literacy, human rights and the environment, we would welcome any developers who want to allocate their 5 days to work with us on addressing these issues.

We would also love if Atlassian could make both JIra and Confluence accessible. We completely depend upon it at the Inclusive Design Research Centre, and are always troubled (deeply) that we can't have everyone in our community participating equally. We've also been lucky to enjoy a great relationship with the Atlassian team and are grateful for the tools we have. We'd love to hear about any initiatives to work on this and if we can help at all let us know!

Jeff - I actually had recommended to Bryan Rollins at Atlassian that they contract Bryan Garaventa who is an amazing blind developer with lots of JavaScript expertise. He could fix issues with all the AUI components very quickly. He's already done some similar work with creating accessible UI components at:

https://github.com/accdc

If there's a good Javascript developer out there who:

• is familiar with screen readers and practical accessibility needs
• thinks they can fix AUI (which is open source) to be more screenreader-friendly, without substantially screwing up everyone else's user experience

How about starting a Kickstarter project, with a concrete goal like "enable JAWS users to search, create and comment on bugs".

If it's compelling I'm sure Atlassian (via the Atlassian Foundation) would contribute, as would other individuals and companies in the wider Atlassian ecosystem. At worst, we get a forked AUI that particular companies can deploy. At best, Atlassian integrates the changes and everyone benefits.

I think there's no lack of willingness here, or even money. Practical accessibility in modern JS-driven apps is just a hard problem. There's very few top notch Javascript developers with good UI sensibilities who understand accessibility and have access to screen readers and a test user or two.

Yes, I was just using VoiceOver on the Mac.

I though that the Atlassian Design Guidelines referred to this, but I couldn't find anything when I looked again.
It looks like there's more work to do around those clever typeahead versions and select list fields, and menu items in general.

Gerardo, was the second part of your video just using the OSX Universal Access VoiceOver utility?

It is ridiculous that this Jira was created 8 years ago and the latest version of Jira is not accessible despite stated intentions in August of last year to address these issues. I have created the following YouTube video demonstrating some of the issues and asking people to push on Atlassian to address these issues:
http://www.youtube.com/watch?v=5yQEDyqt0Iw

I'd also be interested in hearing any updates.

Are there any updates on when/if this will be addressed or what the gap is between the current version of JIRA and the 508 requirements?

The lack of movement on this is really frustrating. JIRA is not Section 508 compliant and I hope no government agencies are paying for licenses, since they would be violating federal law. We have had no luck getting a response on these issues. The frustration by my blind engineers is growing...

Here's Bryans' assessment of the accessiblity issue with JIRA 5.0.

"So the problem is keyboard accessibility. You can't tab to a menu link like Dashboard and activate the menu from the keyboard, then browse the menu items from the keyboard, nor can you close the menu from the keyboard and set focus back to the triggering element. Instead, all you can do is press Enter on a menu link to be sent to another page that doesn't provide the same options. If the other page contained the same links as are shown in the menu, then it wouldn't be so bad, just unfriendly"

So the problem has two parts as I see it.

1) Cannot use drop down menus in JIRA 5.0 without a mouse

2) Actually clicking on the drop down menus does not provide access to the same functionality (if they don't want to fix the menus themselves)

------------

Since the release of Jira 4.2, Jake has noticed the issues below with accessibility. We just recently upgraded our QA instance of Jira to version 5.0 and he is using JAWS 13 and the issues remain:

Comment actions not viewable by screenreader

Component fields not viewable by screenreader

Fix Version fields not viewable by screenreader

Menus not viewable by screenreader

Our internal jira is: https://bugs.benetech.org/browse/DSK-3149

There are a couple of Jira's that are open with Atlassian as well:

https://jira.atlassian.com/browse/JRA-5574

https://jira.atlassian.com/browse/JRA-21725

Confluence also has an open jira regarding accessibility:

https://jira.atlassian.com/browse/CONF-12383

There have been lots of UI changes, but I haven't heard of any of them being for this reason.

Has any progress been made in making JIRA Section 508 compliant in the last year (or WCAG-compliant?) Is this issue still the go-to place for accessibility in JIRA?

Seems like a smart move if we can implement this without much pain.