developersWG 12.02.2019
December 02, 2019
1. The Jupyter Lab Accessibility Workshop that there is a call for proposals due by December 15th. Where we might want to propose a 2-4 day workshop on improving their accessibility.
https://github.com/jupyter/accessibility/issues/11 These workshops are paid by Juypter, we as a community want to put in an accessibility. Our goal is to keep it very tight, not general audience, deep dive lets figure out of the triage, there might not be funding to fix, we need to identify what needs to happen. Berkley might give some money, we would have a set roadmap, but this roadmap might extend into 2022.
Jason: I am not sure at this point, I am interested in helping with testing or bug identification.
Charles: so maybe not at this stage.
Jason: if you want another opinion on solutions. I can help.
Richard: its not in accedemic education,
Sina: in applied sincere, simulations, fluid dynamics, computer generated music / art, applied computer science Jupyter lab. There are 10's of millions of users.
Richard: looks like a platform for doing things, the platform itself is accessible.
Sina: if I wanted to send you some code and a data set, and some analysis, up I could package it up in Jupiter lab and I send you this one thing then on your computer you can run it and you are off to the races. Jupyter is a very rich webpage that can do calculations. F=ma, and can do the calculations, both the output and the platform itself is inaccessible.
Richard: this workshop is more around the paltform.
Sina: Yes.
Richard: we want to create the aria for JL.
Sina: it already uses web tech so implement the aria is what is needed.
Jason: Berkley has an intro to computer science has a Jupiter lab statistics / programming. worth noting that.
Sina: especially online courses MOOC, etc. Sina: its a really cool technology, it is transformative in certain disaplines.
Richard: are you going to do the proposal.
Richard: I think this looks good especially for the next proposal.
Glinda: I would say always look for external funding. we have not had an increase on this line. This is the year for the project managers and I think DIAGRAM should have a presentation at the OSEP project directories meeting.
2. Extended Image Descriptions Library tool that Benetech and W.W.Norton is working on (continuation from the DIAGRAM Code Sprint) (we have a CSUN presentation accepted on this topic.)
... (Charles had to step away - missing notes where George and Evan describe work done to date on extended image descriptions)
Sina: idea of preferences (progressive enhancement) opposed to graceful degradation. anyone can choose to enable some options, visually show image descriptions. what's the feeling response to that by publishers.
George: RS from content. read-aloud functions include alt-text are surfacing. if you want progressive enhancements in the book itself, so you must be in rs with JS. we see JS in the reading systems now. but there are some systems where JS is not present. then this won't work.
Sina: will publishers take advantage of it.
Evan: we are doing this now we are on the content side and the reading system, so I can make this happen. Goal is a tool for reading system, but may not be the we do something for our books on build for kindle. so we just expand it an leave it inline. but its better than a lose of information. We use details for a variety of things. same things with tool tips. footnotes and how they are set in the HTML.
George: in our extended book where we use footnotes instead of just a link to a div at the end of chapter, its a link to an aside to the footnote.
There is also described by which I don't like but publishers use but its not a footnote, but its not really a footnote.
Sina: slap the link inline (2) down to said look note with an aria-describedby describing, if you want to read it, you don't have to scroll down to it, but doesn't work for markup, and it is being exposed to braille.
are we proposing a new attribute Evan?
Evan: RS doesn't support anything modern only links we can count on. We could use the footnote pattern, we could have our role=note doc-noteref and use aria to enhance this. The # of reading system we which need to support is too wide to support this.
SIna: is this a long tail?
Evan: most RS will support JS, but its Kindle that doesn't support it
George: you have to have them publish it. Kindle preview is flakey
Jason: we probably don't want to have to support the RS which doesn't support JS.
George: Joana Hunt from Kindle is updating their system and is working with us.
Evan: we already are doing that for Kindle different one for kindle.
Sina: George laid out we have consensus that details is the best approach, we can get SR support get NVDA, is the obvious best answer. there are 3 other issues
- Kindle is the elephant in the room (I say this should be ignored, and a separate version) Lets go for the nice solution.
- didn't talk about visual UI discussion
- Evan raised should this be injected into the book or should it rely on static in the book and the Reading System Sina: preferences, are important. Evan: during the build process
Sina: we can continue talking?
George: I am under deadlines to survey to the publishers, from our prospective, here is our choices which of these would you be willing to support. all of them provide a better solution than what is there today. I can create the survey and share it with all you.
Sina: I am willing to do that.
Evan: I will review as well George.
Charles: we will continue in email and when we get to the operational aspect of this we will loop you all in again.
DIAGRAM Center Website http://diagramcenter.org