Proposal: Accessibility statement

Help / Discuss
21

The point is not to explain it here but in the doc. It’s not useful to use vague terms that nobody will understand. Either we remove “Self-evaluation” or we detail what it means.

Now, reporting wcag issues or categorizing them is not self evaluation to me. I understand self-evaluation as the capability to track how good or how bad we are at reaching WCAG 2.2 AA, ie where we stand. i can be wrong, but the point is that this term needs to be defined.

22

That was not my point. You said in your original:

I was just asking what process was changed in practice. From your answer, I gather that you didn’t really mean that any process was changed but more that the current processes are exposed.

Side note: I am proposing some process changes in my comments above :slight_smile:

23

Thanks for you work Lucas. I think this is very useful.

24

Here is an updated proposal of the accessibility statement proposed:

Accessibility Statement for XWiki

This is an accessibility statement from the XWiki core Committers.

Measures to support accessibility

The XWiki core Committers take the following measures to ensure accessibility of XWiki:

Conformance status

The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. XWiki is partially conformant with WCAG 2.2 level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standard.

Goals

The XWiki core Committers aim at XWiki being fully conformant with WCAG 2.2 level AA.

Feedback

We welcome your feedback on the accessibility of XWiki. Please let us know if you encounter accessibility barriers on XWiki:

Technical specifications

Accessibility of XWiki relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your computer:

  • HTML
  • WAI-ARIA
  • CSS
  • JavaScript

Limitations and alternatives

Despite our best efforts to ensure accessibility of XWiki , there may be some limitations.

Known limitations for XWiki are listed on our issue tracking system . Please contact us if you observe an issue not listed there.

Assessment approach

The XWiki core Committers assessed the accessibility of XWiki by the following approaches:

Date

This statement was created on the 13th of September 2024 using the W3C Accessibility Statement Generator Tool.

25
  • Add an Accessiblity Manager role (and elect someone) → WIP, should be done soon
  • Write down somewhere how we include accessibility in our designs → We do not have formal design practices yet. There was a project to get one but it wasn’t finalized. I decided to remove the design process affirmation from the accessibility statement proposal. We can add it back later when it becomes relevant :+1:
  • Link to our development practices for WCAG → Done :+1:
  • Link to the accessibility automated tests → Done :+1:
  • Check if SonarQube has some accessibility rules and if so, link to them and consider enabling them for us → I checked and there are some. However I don’t know how to activate them properly. IMO this can wait a bit and we can update the accessibility statement once this is set up.

I added some detail :+1: (see the post above)
Reporting and categorizing is not self evaluation in itself, but it allows us to observe its evolution in time. IMO it’s a good indicator of the state of accessibility. E.g. if at some point the no. of accessibility issues gets to zero it would be a good indicator that accessibility is better at that point that it ever was before. Let me know if you don’t agree with the details I added.

The other points you mentionned didn’t need much more discussion, I addressed them in the updated proposal above :+1:

Thanks,
Lucas

26

Interesting. I can help but the first step is to list which ones we would like to activate. The real question is whether this would be useful for us. If so, then we should start a thread proposal to activate some. It could be a duplicate of our current WCAG tests. However, the nice thing is that our WCAG tests are based on existing functional tests while these rules are static rules based on source files, so it could help find mistakes. It would be good to see if we fail those rules currently and whether the failures are real and not false positives.

If you’re interested by it, it would be nice to create a jira and plan it.

I agree that we can continue the work on the accessibility statement in parallel.

I’d simply write:

Assign clear accessibility goals and [responsibilities](link to the accessibility manager)` (the second link needs to point to a new subsection).

Same for other links, no need to add “See our …”.

What I don’t like with this statement is that it’s too vague. A project that just started working on WCAG would be able to write exactly the same… We need to link to some measure of our progress on the compliance.

Same as above, we shouldn’t add links in the text. Links should be put on words and sentences. In this case:

On our issue tracking system.

I’m curious to know what value this section adds.

What you added sounds good.

Thanks Lucas! We’re getting there :slight_smile:

27

I need to check the exact rules but this will be faster and more convenient to check than integration tests (and contrary to integration tests, it’s trivial to spot out where you might have broken something with your changes).
Created a ticket on jira for this topic :+1:

Removed all the See our :+1:

I’m not sure how to formulate this in a better way. In the template, they had three option: conformant, partially conformant and not conformant. If we want to respect strictly the definition of WCAG it would be only conformant or not. A nice thing with the accessibility statement is that it goes beyond this simple conformance status. A project that just started working on WCAG would not have much in its accessibility statement :slight_smile:

As for a metric for the progress of compliance, we don’t have many numbers that make sense without their context. One number that could make sense is the number of failing test categories from our automated tests. Eventually this will reach (and stay at) zero and we’ll need a new metric but at least that’s something we can use for now…
The issue with counting the number of open issues is that all accessibility issues are not equal in criticity. Moreover, the more refined the experience is for screen reader users and the more issues we can see. As an analogy, if you have a text that’s completely unreadable because of color, you probably won’t see and report the fact that it’s slightly off center.

It was added by default in the template. From what I understand, it means that XWiki will not be accessible for tools (web browsers, screen readers, …) that do not support these technologies. HTML and CSS is hard to imagine, however I can see a new browser not fully supporting WAI-ARIA, and some users disabling Javascript. We inform the user that if they disable Javascript, XWiki will not have the expected level of accessibility.

I agree that the default wording here is quite roundabout, I reworked it to be more to the point.

Since most of the statement seems to be good, I added it at https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Accessibility/ .
Feel free to get another look at it and let me know here if there’s anything else I should add before we consider it ready.

If there’s no activity on this topic for two weeks, I’ll consider the statement ready and close this topic as solved.

Thanks for all the feedback Vincent!
Lucas C.

28

The statement is ready, closing the topic.

29

Thanks @CharpentierLucas for adding it to https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Accessibility/

I think we should also link it from https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HAccessibility because it’s not just for users but also for developers (since they commit to implementing it). WDYT?

Thanks

30

Yup! I’ve replaced the link to the WCAG testing page from the dev practices with one to the accessibility statement (the WCAG testing page can be found from here anyways).
:+1:
https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices?viewer=changes&rev1=227.1&rev2=228.1

PS: I checked the other backlinks of the WCAG testing page and decided to also add a link from the HTML/CSS codestyle: https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/XhtmlCssCodeStyle/?viewer=changes&rev1=36.2&rev2=37.1&

1 Like