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 ☺️