Investigate accessibility statements

[gabalafou]

This Github issue came out of the Nov 11 team meeting: #49

• Tania likes the Gatsby docs accessibility statement.
• Gabriel added Adrian Roselli's accessibility statement

[trallard]

I have shared this gov.uk resources before

• https://www.gov.uk/government/publications/sample-accessibility-statement
• https://www.gov.uk/guidance/accessibility-monitoring-how-we-test

@trallard and @isabela-pf to work on a lightweight version for Jupyter

[isabela-pf]

Discussions were also happening at jupyter/accessibility #72!

[isabela-pf]

Okay, here are some thoughts on accessibility statements based on all the resources previously shared.

What we get from the W3C accessibility statement generator

I started to make an outline, but the W3C's statement generator is a great baseline, so I've filled to the best of my abilitythat out for review below. I think we will want to edit and possibly add to it, though.

⚠️ Draft Accessibility Statement for JupyterLab

This is an accessibility statement from Jupyter accessibility contributors.

Measures to support accessibility

Jupyter accessibility contributors take the following measures to ensure accessibility of JupyterLab:

• Include accessibility as part of our mission statement.
• Provide continual accessibility training for our community.
• Assign clear accessibility goals and responsibilities.
• Employ formal accessibility quality assurance methods.

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. JupyterLab is non conformant with WCAG 2.1 level AA. Non conformant means that the content does not conform the accessibility standard.

Feedback

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

• Write an issue on jupyter/accessibility
  Write an issue on jupyterlab/jupyterlab and request it be labeled tag:accessibility

Compatibility with browsers and assistive technology

JupyterLab is designed to be compatible with the following technologies:

• Windows, macOS, iOS, Android; Firefox, Chrome, Safari, Chromium browsers (mobile and desktop).

JupyterLab is not compatible with:

• Internet Explorer, Edge; JAWS, NVDA, VoiceOver, Narrator, Orca screen readers; voice control technology.

Technical specifications

Accessibility of JupyterLab 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

These technologies are relied upon for conformance with the accessibility standards used.

Limitations and alternatives

Despite our best efforts to ensure accessibility of JupyterLab, there may be some limitations. Below is a description of known limitations, and potential solutions. Please contact us if you observe an issue not listed below.

Known limitations for JupyterLab:

1. Documents: Documents writen by the community may not include accessible content because we do not and cannot review every document that can be opened in JupyterLab. To support accessible documents, we are drafting guidelines for accessible document content with an emphasis on Jupyter notebooks. Please report the issue to the author and open an issue on jupyter/accessibility describing the problem and the behavior you expect so we may integrate it into our content guidelines.
2. JupyterLab extensions: JupyterLab extensions writen by the community may not be accessible because JupyterLab extensions can be written by anyone in the community and have no required review process. We do not and can not review every JupyterLab extension. To support accessible extensions, we encourage extension authors to use existing, accessible JupyterLab components for their extension. We also provide periodic opportunities for community education on accessibility. Please report the issue to the author and let them know the jupyter/accessibility community may be able to provide guidance.

Assessment approach

Jupyter accessibility contributors assessed the accessibility of JupyterLab by the following approaches:

• Self-evaluation
• Regular automated testing to monitor for regressions (can be found at jupyter/accessibility)
• User feedback

Evaluation report

An evaluation for JupyterLab is available at: jupyterlab/jupyterlab#9399.

Evaluation report

User reports on JupyterLab's accessibility are available at: https://github.com/jupyterlab/jupyterlab/labels/tag%3AAccessibility.

Formal complaints

For formal complaints, please

• Write an issue on jupyter/accessibility.
• Write an issue on jupyterlab/jupyterlab and request it be labeled tag:accessibility.

---

Date

This statement was created on 16 May 2022 using the W3C Accessibility Statement Generator Tool.

Things I think we should add

From Make your website or app accessible and publish an accessibility statement - Gov.UK, there are a few things we need to do. I've added check boxes to the quote to show what I think is covered in the above draft.

Your statement needs to cover:

• whether your website or mobile app is ‘fully’, ‘partially’ or ‘not’ compliant with accessibility standards
• if it’s not fully compliant, which parts of your website or mobile app do not currently meet accessibility standards and why (for example, because they are exempt or it would be a disproportionate burden to fix things)
• how people can get alternatives to content that’s not accessible to them
• how to contact you to report accessibility problems - and a link to the website that they can use if they’re not happy with your response.

With this and the other resources, I think we may want to add

• How people can get alternatives to content that's not accessible to them (mentioned above).
• An accessibility monitoring methodology section (ie. the testing work). This could be a link to a document that goes more into detail about this process since I doubt it is the main focus for everyone reviewing this statement.
• Maybe a note about open source. We'd have to be sure not to let this sound like an excuse, but rather a note about response times and that there's no support for this work.
• A way for people to report they'd like to be reached out if/when we are testing (like Gatsby's Surveys and Research section). Since I think this could come off wrong, we may want to mention like "for outreach in any potential paid testing opportunities." At the same time, it'd be useful to know we have people available if we want to apply for funding this kind of work in the future.

What next

To move forward, I would like to know a few things.

• What seems to be inaccurate or missing from this current draft?
• What's on your wish list of statement additions?
• How would we like to collaborate on this next? Is it a good time to open a PR, or do y'all find it easier to iterate elsewhere first?
• I filled this out for JupyterLab. Is there any supporting project we think should be included (ex. the notebook file)?

[trallard]

Can you move the statement into a PR to keep track of reviews and make in-line comments? @isabela-pf

[trallard]

Other resources I have mentioned before are the gov.uk statement and their model a11y statement

The first document has a PDFs and non-HTML documents section - do we have non HTML content we need to add? Does this cover the question

How people can get alternatives to content that's not accessible to them (mentioned above).

An accessibility monitoring methodology section (ie. the testing work). This could be a link to a document that goes more into detail about this process since I doubt it is the main focus for everyone reviewing this statement.

yes - we need to spend some time restructuring the a11y site - to add new sections one of this being the how we test and the statement plus this ties with the work you have been doing in #95 since I do want to add those scripts there

Maybe a note about open source. We'd have to be sure not to let this sound like an excuse, but rather a note about response times and that there's no support for this work.
Yes... and an invitation to folks to contribute which ties with the last point about reaching out

TODOs

• open the PR
• all review
• create an issue template in jupyter/accessibility for the complaints (this might tie with broader improvements the repo needs but this for now)

[isabela-pf]

The first draft PR has been made in quansight-labs/accessibility #3. Once it is approved there it will become a PR to jupyter/accessibility.

[trallard]

Merged - time to open against https://github.com/jupyter/accessibility

[isabela-pf]

I think this should be closed either

• Now, considering this has been created and contributed with some feedback
• Once it is in the main JupyterLab repo (or wherever it needs to live to be linked with that software)

I'm open to either.