We've all been there; started a job and had the coding standards document passed to us to read. As developers, it gives us a chance to decide if we really want to work with the company. We find out just if a company's thought process aligns with ours.
The standards may be a one page document, or a 100 page thesis, they may even point to a set of standards on the web.
This article isn't about what makes a set of coding standards good or bad from a technical viewpoint or even how long or short they should be. It's about whether we've considered our colleagues or the community we've working with when we've defined them.
I want to ask a set of questions based on things we've discussed when we talk about when building accessible websites and applications.
If you don't have a visual impairment (or even if you do), I highly recommend Silk Tied Toolbar, its a plugin for Chrome and lets users simulate some of the issues users may have when using applications. Also download try some speech recognition software and navigate around the web using it.
- showed 1.1% of respondents had difficulting seeing
- 0.7% of respondents of deaf/hard of hearing
- 0.3% can't walk without assistance
- 0.2% find it difficult to type
There are no stats for dyslexia in the figures or colour blindness. In the UK 1 in 10 people have dyslexia and 1 in 12 men and 1 in 200 women are colour blind.
I recognise the list of questions I ask isn't many; want to the barriers to onboard for people with different challenges to onboarding in relation to coding standards.
Using screen readers is memory intensive. Does the concept of "self documenting code" help or hinder a screen reader user. Should we be writing more comments to help screen reader users?
Colour contrast and themes can help people with dyslexia. Tools such as JetBrains can help spell check code. But does the enforcement of variable prefixes help? What about camel case or pascal case which is better?
Should build tools really be used for checking code when thinking about accessibility? If your build always fails because you can't work the way the tool wants you to, for example, some people really need the "_" prefix in order to be able to read a variable, but the pipeline won't accept that prefix. If you can't get the build process fixed, are you going to stay in a job where you have to battle the processes?
Finally don't forget to check that the coding standards documentation itself conforms to accessibility requirements!