- βWe're all temporarily abled.β
- The picture
- Alright, but what should be the vision?
- The details of our mission
- Our promises for the future
- An honest βThank You! β
βWe're all temporarily abled.β
I've heard this quote while brainstorming ideas for this very article.
My initial idea for beginning the article was the very obvious "Let's go with a statistic". Although predictable for an accessibility article, the "1 in 6 people worldwide experiences significant disability" was factual, straightforward and seemed to work.
When a colleague told us the quote in the heading, all these statistics I found started to fade. Although it's a bitter-sweet & quite poetic sentence... why did the quote push the facts on a second place, so fast?
Could it be... that through the lens of an abled person, only the slightly selfish image of losing that ableness makes them truly ponder accessibility?
I've felt the need to negate this, and you may have felt it too, but let's be honest to ourselves...
There is a difference between:
- advocating for something when there's "more free time" or "enough resources to do this" and...
- actually thinking of accessibility as a personal, continuous & necessary mission of our life's work.
β We're all temporarily abled. β Yes, but today is not about our future selves.
It's about all the people who, in 2024, still have obstacles in the way of digital knowledge just because they have a certain form of disability.
- They are young people just starting to learn about everything.
- They are adults working hard every day.
- They are elders trying to enjoy retirement.
The picture
Let's put it another way:
- They are possible clients equating to a 13 trillion dollar market.
- They are talented employees that make a possible 25% of the corporate workforce.
- They are the people that the European accessibility act legally requires some of you to support.
It seems that even objectifying humans in the most capitalistic attractive way possible, we are still not able to influence websites and software teams to cater to the most basic requirements of these people.
Even when moving into "the nice side" of software development, the open-source world, it hurts to say: we should do (much) better.
A throwback to an open-source event this year reminded me how 1/4 of the room left instantly after the title of the presentation was revealed: Web Accessibility and Environmental Sustainability with Popular CMS.
You may think I'm blaming the developers that left, but I'm really not. After all, I get it. They most likely want to learn things that can advance their knowledge and, thus, their career in open-source. If developers see that the focus of their groups is clearly not on accessibility... well, life is short, time is limited, they will focus on other "more relevant" things.
You see... it's a vision issue, but from people that don't need glasses or screen-readers. π
Alright, but what should be the vision?
Accessibility shouldn't be a dream, but a default feature.
The open-source product XWiki started out in 2004 and grew slowly over 20 years. While we didn't have the means back then to build everything according to our very own ideals, in the last years things changed. It may sound pompous, but we knew all along that it is our duty as creators of open-source knowledge sharing software to free knowledge in the truest sense there is: eliminate any obstacle there may be to it.
This obviously meant:
- dedicating time and resources to our roadmap π°
- getting new people on board π©π»
- researching and using tools that could let us identify issues faster π
...all to accelerate our progress to achieving our milestone: the W3C WCAG 2.2 (AA level).
The details of our mission
What is our mission, how did we get to actually do it right, and how is it going?
Powering up our open-source engines π
The XWiki SAS Product Team always made conscious efforts of writing code that improved the project's accessibility.
Projects that contacted our team for custom work with the clear focus on accessibility served as great catalysts in our mission. They allowed us to predict what we need to accomplish these goals — time resources and people —, thus enabling us to speed up our accessibility work, at a stable pace.
The first of these projects came from a Dutch organization in 2009 which was promoting the usage of standards in the Netherlands. They wanted to use XWiki for their website as it was one of the few wiki projects, at that time, that followed the accessibility guidelines the closest. This was the first opportunity that we got to progress on our WCAG compliancy goal.
Fast-forward to this year, the latest happy news on this topic is represented by the BMI (Germany's Federal Ministry of the Interior) funding which focused on heavily improving XWiki's and CryptPad's accessibility.
While it's often a legal requirement, open-source projects' accessibility is rarely getting sponsorships. We hope that through more topic-awareness and collaboration, more open-source projects can get the same opportunities to enhance accessibility.
What are the standards we are trying to adhere to?
While our main focus is meeting Web Content Accessibility Guidelines (WCAG), we also try to solve issues related to other accessibility standards when they are reported.
This includes:
- BITV (Barrierefreie Informationstechnik-Verordnung)
- ADA (The Americans with Disabilities Act) standards
- a11y guidelines — a11y is a community-driven effort to make digital accessibility easier.
We are also looking into solving ATAG (Authoring Tool Accessibility Guidelines) issues in the future.
Testing accessibility efficiently & with ease
Though initially started out using Dutch Web Guidelines to validate accessibility, XWiki moved to using Axe Core since version 15.2 to detect violations against WCAG 2.1 (AA level). Axe Core is a fast, secure & lightweight accessibility testing engine chosen by our devs thanks to its seamless integration in our current testing environment. To perform these WCAG validations, we reused our docker-based functional tests, covering all the static interfaces.
Since WCAG tests are not fully automatable, we manually test our accessibility in the same manner we do manual UI tests and organize manual testing sessions from time to time.
Developers also use WCAG validation tools like Axe devTools directly in their browsers to reproduce issues on their computers with ease. This makes it quick to visualize problems and tackle them.
A list of other possible tools for checking and validating accessibility issues was made available, for those looking to contribute to the XWiki project:
Online | Browser-based | Manual testing checklist |
|
|
A code style that will ensure accessibility on long-term development
To make sure that our current efforts to achieve WCAG 2.2 AA level don't get lost through multiple styles of coding, we organized a best practices page. If you are contributing to XWiki or integrating it, you may find this page helpful.
External audits & openDesk
As you probably already know, XWiki SAS is 1 of the 8 partners included in the openDesk project (Der Sovereign Workplace). As this project is meant to serve the public administration of Germany and any other team that may choose openDesk in the future, accessibility is a must.
A great help in this matter has been DataPort. They organized internal audits on the XWiki platform in relation to the whole project, made recommendations for particular issues and confirmed our rapid progress towards our goal.
A detailed and comprehensive validation of our progress was done by Zendis too, who recently published their audit!
You can read the original document in German.
Here is a summary of the WCAG criterions that are applicable and which ones we... β pass, βοΈ essentially pass or β not pass. Criterions with which we are not fully compliant have a link to their corresponding issue.
Categorization of issues (click here to skip table)
β Passed (37 requirements, 77%) | βοΈ Esentially passed (2 requirements, 4%) | β Not passed (9 requirements, 19%) |
9.1.3.1a HTML Structure Elements for Headings 9.1.3.1b HTML Structure Elements for Lists 9.1.3.1d Content Structured 9.1.3.1h Programmatically Determinable Form Element Labels 9.1.3.2 Logical Sequence 9.1.3.4 No restriction on screen orientation 9.1.4.1 Usable without color 9.1.4.2 Sound can be turned off 9.1.4.3 Sufficient contrast of texts 9.1.4.4 Text resizeable to 200% 9.1.4.5 Avoidance of font graphics 9.1.4.10 Content breaks properly 9.1.4.12 Adjustable text spacing 9.1.4.13 Displayed contents are operable 9.2.1.2 No keyboard trap 9.2.1.4 Keyboard shortcuts can be turned off or customized 9.2.2.1 Time limits 9.2.2.2 Moving content can be turned off 9.2.3.1 No flickering 9.2.4.1 Skippable sections 9.2.4.2 Meaningful document titles 9.2.4.4 Meaningful link texts 9.2.4.5 Alternative access paths 9.2.4.6 Meaningful headings and labels 9.2.4.7 Clear indication of current focus position 9.2.5.2 Pointer gesture inputs can be cancelled or revoked 9.2.5.3 Visible label part of accessible name 9.3.1.1 Main language specified 9.3.1.2 Foreign words and sections marked 9.3.2.1 No unexpected context change in focus 9.3.2.2 No unexpected context change in input 9.3.2.3 Consistent navigation 9.3.2.4 Consistent labelling 9.3.3.2 Labels for form elements present 9.3.3.3 Error help 9.4.1.1 Correct syntax 9.4.1.2 Name, role, value available | 9.1.1.1b Alternative texts for graphics and objects 9.1.2.3 Audio Description or Full Text Alternative for Videos 9.1.2.5 Audio Description for Videos 9.1.3.3 Usable without reference to sensory characteristics (issue #1, issue #2 ) 9.2.4.3 Logical sequence in keyboard operation (issue) 9.4.1.3 Programmatically available status messages (issue) 11.7 Custom Settings (issue) 11.8.1 Content Technology (issue) Accessibility statement (issue) |
Our progress so far
In November 2023, a total of 389157 automated tests have been run. 99.18% of our automated WCAG tests are passing.
There were:
- 1816 warnings left in the tests to fix (0.45%)
- 1349 incomplete tests (0.34%) which need manual validation.
Based on these warnings and incomplete tests, we create issues and solve them in the available time. You can see the open issues here. π΅οΈβοΈ
These tests contain duplicates as multiple issues can have the same few causes.
Note that the automated WCAG tests have 2 limitations:
- WCAG tests are executed only for UIs for which we have automated functional tests available.
- The underlying library we use for testing (AxeCore) estimates that it catches only about 50% of WCAG issues.
- In the future, we plan to also run manual WCAG tests once we've fixed all the issues we can catch automatically.
We track our progress on accessibility issues on our public JIRA, where you can also see our created vs resolved issues chart.
- In the last years, 215 WCAG issues were created π
- Out of these, 183 were solved (85%) β
Last year's progress
During an analysis of our accessibility issues, we've identified the main themes of the issues solved throughout 2023 and 2024.
See the percentages below and the details of the solved issues in this list.
Our promises for the future
- Promise #1: The XWiki software will reach full compliance with WCAG 2.2 soon. π―
- Promise #2: The xwiki.com website will have its accessibility heavily improved in the near future. π
- Promise #3: We will continue to encourage people to take accessibility seriously, not as a nice-to-have, but as a default feature. β¨
An honest βThank You! β
Thanks a lot for reading all of this. It truly means a great deal to know people are interested in the accessibility conversation.
If you have a similar vision to ours, it'd be great to know how you're tackling accessibility issues in your own project or team. Write us on our forum whenever you have the time.
Also, if you have any other questions about this topic from a business perspective, we're one email away (contact@xwiki.com).
If you want to see articles like this more often, don't hesitate to subscribe to our newsletter.
See you next time! π