How to test JupyterLab Accessibility/How persons with handicaps use JupyterLab

[manfromjupyter]

Deaf/Hard of Hearing

• To test, either use the site on full volume and see if you hear anything that the information is conveyed visually as well (Closed Captions, etc).
• To walk in the shoes of a deaf or hard of hearing user, use the software with no volume and verify your experience is not hindered in any way.

Seizures

• To test, just use the site and verify you see no flashing or coloring schemes that invert or switch between in rapid succession. Also make sure you don't see any popups of different colors that open and close quickly. May also need to try hitting submit buttons numerous times quickly to see if multiple modals open up or it opens and closes in quick succession.
• To walk in the shoes of a user with epilepsy or other another potential handicap with seizure risk, you just use it and hope you don't run into something that could potentially kill you. There is not safety net you can use technologically to my knowledge to make this easier/safer. Because it lacks that safety net, that is why it's just straight up illegal in many countries to have flashing content without a warning ahead of time at the very least. Read more

Cognitive

• To test, use the software and verify after every action, you click on another tab or stop using your computer for 1 minute or more. Verify nothing changes from when you last walk away. No timing out of any kind, error and success messages persist until manually closed, etc.
• To walk in the shoes of a user with cognitive handicaps (PTSD, ADD, etc.), just use the site and at randomly intervals need to look or walk away for an unknown amount of time. Come back and verify you did not lose progress with wherever you were on the software or what you were working on.

Color Blindness

• To test, add the Tota11y toolbar to your bookmarks (it's how you use it), or eventually use it from within the product (was proposed earlier). Refresh your page and once it has finished loading (refresh icon no longer spinning) click on it from your bookmark bar. If your bookmark bar is hidden while not on a new tab, reveal it. Once the little sunglasses icon appears in the bottom left corner of the page, click it and then select "Contrast". All the places that pop up with red/pink sticky notes are places with problems. Works for everything that has color that wasn't hacked using the CSS filter attribute (which is still pretty rare). NOTE - for popups, dialogs, and things that are not drawn by the DOM already (require a server call - sorry technical), you will need to reselect the Tota11y toolbar to apply those green and red stickie notes to those as well.
• To walk in the shoes of a user with colorblindness there are some things you can do. For content, depending on the individualm, they will either typically suffer in denial or apply a theme that either corrects this difficulty area or makes it manageable for sites that are not compliant. The user may apply it from the platform level (apply a theme on their MAC or PC), apply a theme to their monitor, may apply a theme via an extension on their bowser, or will find a jupyterlab theme that will make just the software or web app at that url domain appear better. You can try any of these avenues to get a feel for their experience, but for the purposes of the work we need to do, use the site without themes but apply a simulator to cause a change to the experience how some of the most common color blind handicaps (Deuteranomaly, Protanomaly, Protanopia, Deuteranopia, etc) use the site. I don't remember what one I used a bit back in the day but just googling found these that might work pretty easily (all free because they're educational tools to raise awareness - pretty sure): Chromatic Vision Simulator and Color Oracle

Low Vision

• To test, with the web app full screen or full width on your 1280px+ wide monitor or computer screen for WCAG 2.0 compliance, magnify your computer to 200% using CTRL with + for PCs or Command with + for MACs. For WCAG 2.1 compliance, magnify your computer to 400% instead. Verify that in doing so NO feature, button, piece of text, etc outright disappears that isn't replaced with something else that conveys the same meaning or functionality. For example, it's okay if all of the links disappear in the header so long as the hamburger menu that takes its place contains all of those links and they still preform how they would outside of it (so cause a secondary dropdown when selected, etc). Alternate way to test is instead test on a small screensize to test for mobile and tablet users. If the viewport meta tag is applied to the site (which it is in the HTML Head), these things are almost identical. The latter is not the most genuine to low vision users but as far as WCAG compliance is concerned, all of it is covered. If button is too small to press on mobile or too hard to read it's the same as being too small on low vision. Similarly if hovering over an element to read it's HTML title element is required to gain the necessary context or meaning, on low vision (magnified view) it will still show up as what looks like 6 font text (which is too small) because it doesn't get magnified when everything else does and for mobile won't render at all. Both of these are avenues are sufficient for testing.
• To walk in the shoes of a person with low vision, there are a biblical amount of tools you could use because, next to color blindness, they are the most common handicaps (just not always reported). Because, although not as severe, this affects nearly everyone after they reach a certain age, lot of tools are available. In practice, low vision users may magnify the page using the same keyboard keys as shown above. On mobile and tablet they may use the double tap gesture to quick zoom or pinch to zoom in exactly how far they need. On their platform (MAC, PC, XBOX, etc) they may magnify everything as a whole to an unknown unmeasurable amount, On MAC they might program a magnify gesture or enable to make their cursor 5 times the size if they move it quickly. On their browser via an extension or with an app user might add a virtual magnify glass or, like my grandma, will hold a real magnify glass against the screen to see what it says.

Ambulatory

• To test, tab around without a screenreader and verify you can get around and that the focus of your tab is always exposed. Verify buttons and actions can be executed using both space or enter key and forms and fields can be used using arrow keys and typing. With a screenreader (recommend Jaws but as of June 2020 this is no longer free, so I guess NVDA) verify it's speaking what you're tabbed to properly and you can use the arrow keys to better get around elements on sites that don't work properly with tabs. There are other software specifically tailored for users with this handicap but I've only ever used general screenreaders. In theory any combination of keys to get around automatically fails because a mouthstick can only physically press one key at a time, but I think these other apps may better provides workarounds for this or generate less noise because it's understood that the user will need that (just has to keep looking up after typing something).
• To walk in the shoes of a user with paralysis or missing limbs, put an unsharpened pencil in your mouth or a plastic spoon or whatever you have similar to simulate using a mouthstick and use the site. No using your hands or elbows. If you can't get around properly or use something an abled bodies person can use, record the failures. Use the keys mentioned in the "To test" section above. Activate a screenreader and enable using arrow keys on things that are not just forms (will allow you to go html element by element).

Blindness

• To test, turn on your screenreader (recommend Jaws but as of June 2020 this is no longer free, so I guess NVDA). See if the site works appropriately and is conveying all the necessary information. Verify the same buttons as ambulatory handicaps still apply (buttons work with enter AND space keys, tabs work, arrow keys, etc). Should also test jumping heading by heading, role by role or region by region, list all links on site, list all tables, do table cells announce what column and row they are in, etc.
• To walk in the shoes of a user with blindness, power up your screenreader and then either turn off your monitor if using one or turn the brightness of your laptop to nothing (assuming it goes to pitch black - MACs do but some PCs don't go that low). Then unplug your mouse and see if the site works appropriately in every feature. You can instead close your eyes but in terms of speed, this is less tempting to cheat and more accurate because blind users tend to know their keyboard better than you and know more hotkeys and you will need to type things appropriately.

After WCAG 2.1 Compliance

Where we go beyond the WCAG requirements is doing just these operations to figure out where there is excess noise that we can trim down to make these users more efficient or what could be improved and continue to deliver on. Apart from education, which I encourage all to do, it does not make sense in doing this all now if the purpose is to expose more issues as we have already highlighted a plethora of things to already fix (and I dare say 99% of all things that possibly need to get fixed for achieving the bare minimum in compliance). BUT, the information is here and we/I intend on continuing after achieving compliance to continue what else can be done. Until then, I encourage everyone to stay focused on tickets derived from #9399 and those issues in the current JupyterLab Accessibility Roadmap.

[choldgraf]

This is amazing! Do you think it'd be helpful to start a documentation site for this accessibility repository? It could act kind of like a team-compass focused around this topic, and include practices like these? I am happy to whip together a little sphinx site with y'all if it's helpful

[manfromjupyter]

@choldgraf I like the idea but don't want us as a team to get distracted documenting and making it pretty instead of working on getting us over the finish line here. Late term might be super valuable but seems fine in here for now. I only documented this because it came up in conversation in the meeting, seems necessary to the quality assurance of their development, and I haven't had the time/skillset to contribute elsewhere (especially since I'm not a TypeScript guru). I leave it open to other people, but I'd say it's fine here for now.

[isabela-pf]

I just added it to the documentation issue #15 so that we remember to add it but don't have to spend time on it immediately. I think that addresses both of your comments, but let me know if you need anything else.