For the accessibility assignment, I decided to look at the OpenROV forum. The project itself is large and multifaceted, but one would imagine that the forum, being relatively simple web design and meant for human interaction only (rather than attracting customers, say) should be accessible.

SiteImprove

Using the SiteImprove accessibility checker, I found that the user avatar images have titles instead of alt text describing the user. There were multiple instances of low contrast text as well. Link text was insufficient to determine where the link leads in many cases and aria-label was not provided for many links.

JAWS ScreenReader

Image titles were enough to describe images instead of alt-text. While aria-labels were provided for some buttons they were insufficient to describe the button out of context. The button for following a topic was not accessible via the screen reader and keyboard alone.

Some improvements that can be made immediately are increasing the contrast ratio on low contrast text, adding more descriptive links or adding aria-labels to the links, and making all buttons keyboard accessible.

I have worked as an engineer for a few years now. And since the very beginning git was part of the workflow. I started out by pushing back. I forced people to send me zipped files and did the version control myself. This works for small projects but it’s terrible for maintaining anything larger than a text file.

I reluctantly accepted git and GitHub; slowly. I started out learning git for maintaining personal projects, with low stakes. I maintained my CV in git, maintained a few Arduino codes here and there. No big deal. For the most part, git was just a way back machine rather than and serious version control. No fancy branching or issue tracking, just a backup for old code, in case I need to get back to it. When my laptop was stolen I doubled down on using GitHub for backup. I now have well over 50 repos, most of them horribly maintained spaghetti code with the last commit made a year ago. They’re not meant for collaboration.

I’ve made a few blunders while using git. I’ve published IP protected code publicly without a license. I’ve had ‘detached head’ errors and ‘merge conflicts’ and while fixing them I almost destroyed repos. But I’ve learned a few lessons from all this. Here’s what I’d tell my past self:

• It takes less time to learn git than to do manual version control
• Don’t be ashamed to publish your code. No one’s gonna read it anyway.
• You can’t push and pull too often
• When in doubt don’t just read a forum post and use the -f flag. Talk to an expert or think about it.
• There’s no shame in using a GUI to interact with git. GitKraken is beautiful!

I’m still learning and I’m still making mistakes that seem ridiculous with hindsight. But I’m happy that they’re at least public.

Reflections on readings:

I connected to the message of inclusiveness in multiple readings. Whether it be by simply being polite to n00bs or going out of your way to include diverse groups often at cost to the project. I think more transparency and diversity leads to better projects. That said, the old adage ‘A committee should consist of three men, two of whom are absent.’ also springs to mind. We should be aware that inclusivity comes at the cost of overheads and slower decision making. We should not be quick to forget the fruits reaped by grace of the BDFL’s.

Personally, I will be more mindful and sensitive towards feelings of anonymous people on forums. And practice polite discourse or refrain from commenting.