Replies: 3 comments 2 replies
-
NotesTony's ideas:
Saul: How do we know what to focus on? Isabella: Blindness is to capture a lot of things. We currently have this project board: #32 Our goal is WCAG compliance. We cant test some of them, because you cant get testing. Nick: People use nonfree screen readers. Screen readers are expensive, if you are deaf and blind and you are using a braille screen reader, that machine is thousands of dollars. Can't imagine testing against it. Isabela: We have had the privilege that other people have tested already. Three-year-old issues, that we haven't given attention too. Tony: JAWS. NVDA, and WAVE are testing schools. These test against standards, not screen readers. Nick: Yeah they are not representing a screen reader, but aren't pretending to. A thing that just came up is icons. All the icons in lab, don't have any semantic meaning to them. Just have photos, not much metadata. Reader will say Tony: Resource throughout all of this is a11y project. One of their suggestions is to have a no mouse day! Nick: Long running issue is losing output, because of closing long running job. If we had this on the server, would make a lot of things possible. If you don't have to talk to a websocket. Would be nice to deliver a first class jupyter experience, with widgets, to the terminal, because its more robust here. If ipython could edit a notebook, that would edit and run, and see output of, would allow us to describe some of these things. Tony: The terminal has been accessible for a while, including tools like hypterm. Tony: Want to split into two groups. Now that binder is merged, easy to do README things. We can help fill out the README, have PR open for this. Other one, is that we have a lot of good notes in our issue from last one. Would be helpful to move this to a discussion. We have been getting a lot of good documentation resources, in short term, would be to put into a discussion. The two groups will split off, one group to do README, the other triage? Isabela: This is the learning meeting, just FYI. Other meeting is for project management. They switch every week. Tony: Actually MJ and I will stay here and look at issue! Other group notesNotes from subgroup: Issues: jupyterlab/jupyterlab#8832 Color contrast tooling: https://www.tpgi.com/color-contrast-checker/ Current at command palette proposals. For example, when we have darker highlight over text boxes, we have some issues:
So I was proposing it has an outline. All you would have to do is which variable it is. Why is it grey when others are blue? I have proposed solutions for the command palette, feel free to review it. If you want to look at putting things into code, I can help there. Easiest place would be to start there. Other option would be to review other parts of the UI. The command palette has the most violations. You could go and audit some other region! Or if you wanna jump straight into code. If you want practice doing a PR, you could get practice, just changing a part of it, like change outline. READMETony: We need some badges, we need some color. They are going to have a bunch of badges, for gitter, the calendar, this is a matter of learning some markdown, to make some pictures and links. If you all could aggregate find all the resources, so they know when the meetings are, they know where the chat is. There is a great resource for making a README: https://github.com/noffle/art-of-readme Badges: Here's an example of how those badges get applied in a tiny markdown readme: As new people, what is that you need to know? Comment on the PR, things I wish I saw when I showed up at the repo. we have lost all that, since we have been here a while. Isabella: Would be helpful to have some direction, for anyone to comment. Sara: What is the difference between a badge and a hyperlink in the text? Isabella: Functionally the same, just break it up visually. Quinten: I didn't know how much freedom we really have, but it doesn't seem like that beginner's eye can be helpful. Sara: We should put badges in our readme too! Tony: Demoing how to find markdown Copy Gitter badge from JupyterLab readme source. Copy and paste into issues. Remember alt text, after link! Reference: https://daringfireball.net/projects/markdown/syntax#img |
Beta Was this translation helpful? Give feedback.
-
|
these notes are killer. thanks for doing this saul. |
Beta Was this translation helpful? Give feedback.
-
|
In response to #27 How/why are we prioritizing what we are for JupyterLab?
|
Beta Was this translation helpful? Give feedback.
-
|
Disagree with starting with blind users. Blind users can't be supported or even tested until ambulatory are working to start and if it only takes a week to support I admit, I should have created different subtickets and/or in a different order, I just had different expectations in terms of speed I have since readjusted. Will see if I might be able to get authorized to take some time to code towards this. I think we need to get the color blind users all squared away that's a very basic 1 ticket worth of work to my knowledge (detailed below from #9399). The person that fixes it just needs to know CSS, just use the Tota11y bookmarklet for it to output exactly what to change each of those too. Then get the Low Vision users done at the same time as supporting mobile-tablet support. I started working on detailing the fixes for this last Wednesday but never finished making it. It's really not much, almost entirely CSS. Then finish ambulatory by doing 3 things: add tabindexing, make the content index in a logical order (which will just be moving blocks of code or hardcoding the indexes), and then have the focus always visually exposed (to whatever you're tabbed to, just add CSS). All of that together lays the groundwork and finishes a bit of Blind users as well. We already have users with Deaf/Hard of Hearing, Seizure, and Cognitive disabilities squared away, so then we can tackle Blind users. I advocated for the completion of the landmarks ticket #9411 and #9622 (purely for blind users) because it completely knocked off a section we had to do, was the least we could do to help blind users for now, and allowed us to then splinter the rest of work for blind users from there because we could navigate around now. Hard truth, blind user support will require refactoring every panel and modal of the product and making sure we are revealing what needs to be revealed, hide what is decorative, and make sure it's efficiently done. We can get most of the hard work out of the way by supporting ambulatory users but it is my opinion that we need to finish the other disability groups first because they'll be so quick. I think there is plenty of work to go around and we can have people work on multiple sections including blind solutions but think our voice and/or direction should be that we're trying to support as many people as fast as we possibly can. Work that is left (and how to do it)Color BlindnessFor color blindness, you do these 8 CSS changes as detailed in #9399, and we can say we support 8% of the male population and 0.5% of the female population that we didn't previously (Source: colorblindawareness.org).
Low Vision
Ambulatory3 things:
BlindRefactor every panel and modal of the product to ensure they have the necessary aria elements, speak the correct information to the user, in an as efficient way as possible, and with none of the noise. (Requires HTML, JS, and TypeScript knowledge and have to touch just about every section with text or icons in the code - so will take a while even just to merge). Comes out to like 30 things
|
Beta Was this translation helpful? Give feedback.
-
|
Just because I mentioned it earlier, wanted to bring up the creation of the 2 tickets to address Colorblindness and Low Vision support. One bite sized ticket to completely (or 99%) knock out the WCAG support for these disabilities so we can just focus on Ambulatory and Blindness.
|
Beta Was this translation helpful? Give feedback.
-
Welcome to our second hands on accessibility community meeting. These events are for learning and sharing knowledge about accessibility within our diverse, growing community. On alternate week,s @isabela-pf will run our project meetings.
we'll split into groups and
work/learnhave fun together.please use this issue to add meeting notes by adding comments.
Beta Was this translation helpful? Give feedback.
All reactions