Planning to make the frontend more accessible - Option to get this into the core code?

22 views
Skip to first unread message

Marvin H

unread,
Nov 7, 2025, 7:12:33 AM (3 days ago) Nov 7
to BigBlueButton-dev
Hello everyone! 

We are a university and very keen on making everything as accessible as possible. We are planning to work together with a development team to get the whole frontend fully accessible (WCAG and BITV). We would of course like to push this back to the main branch and are planning to set up a PR for this, after we are done. However we haven't committed anything before and probably will just be working on this one big project. I have read your documentations on how to get PRs approved more quickly, which is why I am worried that our changes might be able to not make it into the main branch. We would like to do everything possible to have this fully accessible final frontend be in the main branch for everyone to use! 

Is there any way to get in contact with the main persons or to maybe connect our developer team with them to make it as smooth as possible for both sides?  I guess this will be a win-win for both sides :)

Thanks a lot in advance,
Marvin

Marcel Hellkamp

unread,
Nov 7, 2025, 11:05:59 AM (3 days ago) Nov 7
to bigblueb...@googlegroups.com

Hi there,

just some general advice for contributing to any open source project:

Do not try to solve all issues in a single large pull request. It require a lot of time and energy to review those huge PRs and you will likely have merge conflicts before anyone has any chance to look at it. You'll end up with a fork that you have to maintain yourself forever because the upstream project changed too much and merging is now impossible. Would not be the first time this happens.

Instead, start small, and keep sending small but complete PRs one after another. The smaller the better. The perfect PR fixes exactly one thing and is so simple that an experienced maintainer can see at first glance that it does what it says, and just merge it with a single click. This strategy also ensures that you are not wasting too much energy on parts of the code that change while you are working on them and then cannot be merged.

If you follow this advice, then you usually do not need to coordinate with the maintainers in advance much. Just start with small PRs and let them speak for you. If they are good and bring the project forward, they will be merged. If not, then ask for advice on how to make them better. Learn along the way and build trust. Become part of the project. That is always the most sustainable way to contribute.

VG, Marcel


Am 07.11.25 um 13:12 schrieb Marvin H:
--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bigbluebutton-dev/a16224da-262e-486f-b0c0-35631128e13cn%40googlegroups.com.

Martin Thomas Schrott

unread,
Nov 8, 2025, 4:39:36 PM (2 days ago) Nov 8
to bigblueb...@googlegroups.com, Marvin H

Hi Marvin!


there are a lot of improvements for v3.1 that where made and some of them are not implimented yet.

Daniel Schreiber and I did invest lots of hours to fix accessibility issues and most of them where already included - the ones that are still missing should be somewhere in the github issues open or at least known by Anton of BigBlueButton.org ;-)

Maybe you can get in touch with Anton and double check you do not want to fix something we already fixed.


The biggest problem at the moment still is the users section of v3.1 - but this is already fixed with a pr in v3.0 which was not used for v3.1 until now.

Anton is aware of this one and I hope it will be included soon.


If you have special issues or exact descriptions just post them on the list for reveryfication if someone already had worked on it - I guess this should help to prevent double work.


best 

Martin

Reply all
Reply to author
Forward
0 new messages