Should we propose merging Accessibility calls into the Frontends weekly meeting?

[ohrely]

As discussed in #146, there is a general sense among many regular contributors to the accessibility subproject that there is not enough activity/bandwidth within our community to make effective use of the current twice-monthly meeting blocks.

In today's accessibility call we discussed at length the idea of folding accessibility subproject meetings into the weekly frontends meeting. We (@afshin @bollwyvl @ohrely @tonyfast) came to consensus on the following proposal:

1. Rebrand the existing weekly Wednesday Jupyter Frontends meeting to a Jupyter Frontends and Accessibility meeting.
2. Remove the existing alternating Thursdays accessibility meeting from the Jupyter Community Calendar.
3. Advertise that accessibility topics are welcome in all of the combined meetings but members of the accessibility subproject will make a particular effort to attend the first meeting of each calendar month.
   • While most accessibility meeting regulars are already also frontends meeting regulars, prioritizing this way should reduce the burden on accessibility contributors who prefer not to attend all four/five calls per month.

Unlike the recent merging of the lab and notebook subprojects into frontends, accessibility would continue to exist as a distinct subproject from frontends. This proposal is inspired by the (apparently quite successful) combination of the server and kernels meetings.

Let's discuss here as a community, and if there's general agreement on this proposal (or a variation) by the 6/26/24 frontends call we can present it to the frontends community for consideration. If the frontends community seems amenable to merging the calls, we will call for an official vote in both communities.

[ohrely]

I am personally enthusiastic about this proposal.

As an accessibility council member, I expect our efforts would benefit enormously from the additional attention and expertise of the frontends community. Products owned by frontends represent a significant proportion of the accessibility improvements urgently needed across Jupyter. Sustaining meeting momentum would cease to be a concern. We would likely catch the attention of potential contributors who wouldn't otherwise know there was an accessibility effort to join.

As a frontends council member, I see only upsides to combining the two meetings. Accessibility should be a key consideration in any changes that impact lab and notebook users. Accessibility pitfalls may get caught earlier in design/implementation discussions, saving effort at the review stage. Frontends contributors who want to get more engaged in accessibility can get involved without an extra meeting to attend (especially valuable for folks in time zones where typical Jupyter meeting times are inconvenient).

[jasongrout]

Ely, you make some very good points. After reading your thoughts, I'm also in favor of proposing this idea to the frontends subproject and trying it out. Thanks for putting the proposal and your thoughts about it here!

[afshin]

I was unable to attend the Jupyter Frontends call yesterday. Did this subject come up?

Maybe we don't yet have buy-in/consensus from the @jupyter/accessibility-council (so I'll ping them here 🤓).

[ohrely]

Directly pinging @trallard @ajbozarth @marthacryan @gabalafou @krassowski @isabela-pf for awareness. I'm planning to bring this up in tomorrow's frontends call, will hold off if anyone thinks it needs more consideration.

[gabalafou]

To me this is a wonderful example of community input leading to better solutions. Thanks for shepherding this, @ohrely!

I'm in favor of this proposal!

[trallard]

I am +1 on merging the calls. Thanks for leading @ohrely ☺️

[echarles]

Just read jupyterlab/frontends-team-compass#251 (comment) posted by @tonyfast which links to external resources and have 2 questions:

1. Is there a Jupyter landing page that gathers all those awesome information (like a Readthedocs)?
2. I remember a demo given by @tonyfast with a notebook built in pure html (with html tag logic and so on). Is that work documented, available somewhere?

[tonyfast]

1. Is there a Jupyter landing page that gathers all those awesome information (like a Readthedocs)?

there are jupyter accessibility readthedocs. many of the useful resources were seeded by design efforts started by @isabela-pf and continued @steff456. we should be thanking and acknowledging their past work when it was not given proper consideration.

currently, the docs are not up to date. unfortunately, jupyter lacks ANY cohesive accessibility strategy or awareness of the disabled experience. as a result, the accessibility meetings folded and accessibility research is not being transmitted to the project. it would be good to keep these docs in a visible evergreen place. perhaps, @ericsnekbytes and the docs working group could take on these efforts.

2. I remember a demo given by @tonyfast with a notebook built in pure html (with html tag logic and so on). Is that work documented, available somewhere?

i really appreciate you asking about this work eric. unfortunately, this work is not documented in formal writing. this work certainly suffers from writing not being my strength, and i lack the bandwidth to put in the effort when i need to design html for assistive technology, implement complicated ci environments, manually test the results on multiple screen readers, and organize community events. i've had multiple conference spaces reject proposals to present this work, and i can't overcome the rejection to continue to promote this work. instead i've recorded some live streams about the works and produced html documents that describe the history. these alternate media formats can be found through the following links.

1. notebooks for all community meeting 1 summarizes the overall effort effort.

   the work is supported by 3 notebooks:

   1. top level notebook for the stream
   2. a notebook about the notebooks for all history
   3. a document on semantically meaningful notebooks

2. the following month we talked about the blind low experience and non-WCAG guidelines we can use to develop assistive software

3. another way to follow the work for jinja literate folks is to look at the nbconvert-a11y templates that build off nbconvert. there are several options to enable testing with effected users.

again, i'm very much looking for someone to make space for me to share this work. if anyone can support me in that i'd really appreciate. i struggle with the effort because i know it is good for disabled folx, but i lack the support to promote it.

[echarles]

Thank you so much @tonyfast for the useful information and links.

I hope your call for more help and community support will be heard. I'd love to contribute at some point when I will have more bandwidth.