I am looking into deploying JupyterHub for the classroom but before I can, I need to look into the accessibility of the notebook interface. Google-ing and searching hasn’t been fruitful in terms of finding materials about the accessibility of jupyter notebooks.
SO! Does anyone have resources for accessibility around jupyter notebooks in general, and jupyterhub specifically? Thanks!!
Only a partial answer but I have seen discussions and Pull Requests on this topic for nteract.io.
Maybe digging around https://github.com/nteract/nteract/search?p=1&q=accessibility&type=Issues will bring up something in terms of assessing current state of things that can be transferred to general Jupyter UI? Or at least asking the nice people of nteract who I think have opinions and skills in this area.
Also https://a11yproject.com/ as a starting point that I think could lead to some kind of tools that generate a report on how good/bad an interface is.
I’ve also been wondering about notebook / JupyterLab themes in an accessibility context - eg high contrast or dyslexia/colour filter themes. I’m not sure if there’s a specific need for something like zooming or font selection / resizing?
I believe that @yuvipanda has spent some time looking into this as well for Berkeley. I’d really love for Jupyter to have some kind of “official” recommendation for a11y, even if the community admits some specific shortcomings (and points of improvement) in the base tech
I’d love to get official a11y support integrated throughout (all) jupyter projects. We’ve struggled to get enough time to collaborate between folks who know the a11y stuff together with folks who know Jupyter. Several projects have been proposed/started and not gotten very far. Berkeley has a great accessibility team that can be a help.
A good writeup of:
general accessibility guidelines
specific problem areas for Jupyter
how to find what should be improved and how it should change
ideally, testing utilities (CI would be a huge bonus!)
would be terrifically useful.
The notebook has issues open on accessibility, and a lot of them have come recently from some accessibility testing folks at Microsoft. But we we haven’t received super useful guidelines/development help on addressing these.
Walking the dog just now, I pondered how repr machinery could feed into extending accessibility. For example, generating simple long_desc descriptions for matplotlib charts displayed through img tags in output cell by “textualising” certain chart attributes - axis names and descriptions, chart type, etc.
The separation of markdown, code and code outputs presumably simplifies accessibility considerations if you work on those structures. (Things like the jupytext formats also provide simpler text representations without the JSON markup.)
I’ve always thought there were two likely ways forward:
if extensions are developed (and perhaps later backed in) it would probably makes sense to generate outputs directly from the JSON;
developing an accessible theme or, better, accessible template, could provide a custom UI enhanced for use by screenreaders etc?
Picking up on the idea of making notebooks accessible by not using the notebook interface, I wonder if there’s a way of developing something like nbplayer as an accessible notebook player?
Searching for tools that would help me get started on the topic of “accessible web apps” I found http://chromelens.xyz/ which makes it easy to simulate various levels of vision impairment.
Maybe using the notebook with the “0% vision” setting and a screen reader would make a good starting point. Maybe not the best way to find formal a11y things but probably a good way to get a feeling for what the user experience is like.
I’m still looking for a simple way to disable all CSS in my browser.
It would be fruitful to split this discussion into at least two topics:
How can we ensure that the Jupyter front end is accessible?
How can we help our users to produce accessible notebooks / content.
I think it would help a lot, since anyone can produce arbitrary content in the notebooks and thereby it is virtual impossible to ensure the a11y validity for this. But having a proper audit for the interface would be a start and you can do a lot good for a11y by just touching the theme / css, at least as a start.
An aspect not covered yet (according to my short rescan of the thread) is documentation.
For example, one rule that is violated a lot in today’s “modern” web is contrast – having the color of your main text pushed beyond the #333 point is a major but all-to-common sin. And simple black is still the best you can do when it comes to a11y.
Making sure your text supports browser reader modes and services like Pocket is also a plus (effectively a way to ‘remove CSS’).