Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mar 3 2021 working meeting #23

Closed
tonyfast opened this issue Mar 3, 2021 · 11 comments
Closed

mar 3 2021 working meeting #23

tonyfast opened this issue Mar 3, 2021 · 11 comments

Comments

@tonyfast
Copy link
Contributor

tonyfast commented Mar 3, 2021

Welcome to our first 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.

if you are seeing this issue, please react to issue with each thing you want to participate in, you should choose more than 1.

  • ❤️ i'm happy to be here!
  • 👀 i want learn about accessibility by reviewing existing issues and pr's
    • fall down the 9399 🐰 hole
  • 😄 i want to work on the readme with @isabela-pf only requiring markdown knowledge
    • add badges to gitter, google calendar, discourse, other meetings folks can go to, edit the contents of the readme
  • 🚀 i want to work on tasks that only requiring css knowledge
    • are there some css specific issues somewhere?
  • 🎉 setup jupyterlab/lumino dev environment only requiring conda & 😿

we'll split into groups and work/learnhave fun together.

please use this issue to add meeting notes by adding comments.

links > substance > style

@tonyfast
Copy link
Contributor Author

tonyfast commented Mar 3, 2021

@saulshanabrook
Copy link
Contributor

saulshanabrook commented Mar 3, 2021

Notes:

Notes from breakout room:

  • What is a readme?
    • @Quinten: We talked about it a little yesterday: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-readmes
    • @isablla: We want to clean up the README and make it more fun! We now have control over readme
    • You can use the "lazy" way to edit the readme, by clicking the edit button
    • Markdown is the friendlier face for HTML. Instead of all the tags, you just have the little characters.
      • # sign gives layers for navigation, makes the title.
    • @SaraBrown: What's opening as a PR mean
      • Github is a system for asyncrounous communication
      • A PR is please add my commits to another place. "Pull Request" I am requesting they pull in your changes. You can pull between any branches
      • ** is for bolding text
      • Did some demo for branches
      • If you coordinate on different lines/files, then y
      • ou avoid conflicts. Thats why some people start commenting on issues and things. So that people don't conflict over the same work. Github will complain at you.
      • "Draft" pull requests
      • sara What is +2 -0 mean?
        • it means how many lines you added and removed.
      • quinten: The eventual plan is for each of us to take as section to make small updates?
        • isabela: yeah that's the easiest way to do it. People can work on the same area.
          • Yeah like for Alt Text and Marking Elements Decorative jupyterlab/jupyterlab#9682, someone could split it up into different parts. What I am saying is there may not be different issues. There are so many of them.
          • Saul: Maybe we could split them up?
          • Isabella: Yeah I did that with WCAG. Made a project for it. I broke up thomases big PR (add link). This is more for my todolist, so I have an easier time: https://github.com/orgs/jupyterlab/projects/1
          • People like small PRs.
          • Isabella: Github projects are a way to have a high level overview of things. Projects are useful to divide things up. I have these in a lot of columns, to sort but what part of WCAG.

@bollwyvl
Copy link
Contributor

bollwyvl commented Mar 3, 2021

here is another nice comic.

@bollwyvl
Copy link
Contributor

bollwyvl commented Mar 3, 2021

for your perusal:

  • this is some work we started on pydata-sphinx-theme: PR, with the goals of:
    • establish a baseline of rules the project
      • rule sets, roadmaps for things known to be improved
    • be able to do "best effort" testing of static websites to on a local computer and in continuous integration
      • capture the results as annotated screenshots, HTML, machine-readable JSON
    • be open source 🎉

@isabela-pf
Copy link
Contributor

isabela-pf commented Mar 3, 2021

Responding to

are there some css specific issues somewhere?
#8832 is a work in progress, but will be mostly if not all CSS.
#9682 is in HTML, but requires a similar level of knowledge.

Flow chart for different types of alt text and how to use it (@melissawm): https://www.w3.org/WAI/tutorials/images/decision-tree/
Their overview for alt text: https://www.w3.org/WAI/alt/
The github project for tracking all JLab accessibility issues: https://github.com/orgs/jupyterlab/projects/1

@MarsBarLee
Copy link

MarsBarLee commented Mar 3, 2021

Example of the importance of using the correct HTML tags for screen readers.
Labeling a title 'How to make cookies' with the Heading 1 tag,
< h1 > and labeling 'Ingredients' with Heading 2 tag, < h2 >.

The screen header will read out 'Header 1: How to make cookies' and 'Header 2: Ingredients'.

Less accessible version:
'How to make cookies' and 'Ingredients' with no heading tags. Instead, text is only visually made bigger and bolder.

The screen header will read out 'How to make cookies. Ingredients'. Less clear.


In screen reader skimming mode, for example it can read out only the < h2 > headers 'Ingredients. Techniques. Steps. Substitutions'.

@manfromjupyter
Copy link

^ Just adding onto to @isabela-pf's comment regarding CSS specific work. There's also the low vision (same as mobile/tablet responsiveness stuff), which will be all mostly CSS and a small amount of HTML (in the form of Typescript returns) fixes, but I don't think I've created exacts on this yet but can next week. I definitely feel the color changes are definitely the perfect thing to get your feet wet though with CSS, using the Tota11y toolbar (should you decide), using github, and maybe also using the built-in browser Inspect Element.

In terms of impact we would be able to declare we officially completely support color blindness (only leaving low vision, ambulatory, and blindness left to provide solutions for).

@bollwyvl
Copy link
Contributor

bollwyvl commented Mar 3, 2021

we should just ship tota11y in core 🦆

@bollwyvl
Copy link
Contributor

bollwyvl commented Mar 3, 2021

potentially related, at least in proposal rubrics:

@manfromjupyter
Copy link

we should just ship tota11y in core 🦆

Complete side note, just wanted to add, yes it could help us test things 20 seconds faster, but perhaps could allow people to review notebooks for accessibility before they ship/bundle them up for their coworkers, classes, etc (if there is a use case for that).

@tonyfast
Copy link
Contributor Author

tonyfast commented Mar 3, 2021

allow people to review notebooks for accessibility before they ship/bundle them up for their coworkers, classes, etc (if there is a use case for that).

I <3 this a lot. currently, there is no idea of caption for matplotlib images or alt text in svgs.

there might be some upstream nbconvert changes we could make based on the nbformat that be expose a more accessible in the static renderings.

we could also think about how the metadata could be used to define accessibility attributes. potentially you could edit roles/titles/aria directly in the metadata

@jupyter jupyter locked and limited conversation to collaborators Mar 17, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants