|
1. Do indentation right. One of the hardest things to do with a screen reader is indenting to a symbol. If we have a statement that doesn't fit on a line, it's much easier to increase the indentation by one level than to make the line start at the position where a symbol like ( is. The screen reader can tell you how many spaces of indentation you have, but figuring out where that symbol actually is and if it looks good is a real pain. This also applies to other situations where the exact number of whitespace matters like making struct declarations in c or go into a table, where one column is the name, one is the type and one is the comment, and spaces are used for alignment. If you really care about screen readers, I think tabs are a better idea for indentation, I feel they're a bit easier to use, though that may just be my preference. One language that got this horribly wrong is python, four space indentation and a lot of starting the next line exactly below a particular character on the previous one. A language that really got this right is go. They use tab indentation and they have that amazing tool called go fmt that basically does all the work for you. It basically formats your code in the standard go way. Yes, go aligns structs with spaces but I don't particularly care in that situation. I never use that convention in my code, I just run go fmt before committing and I'm sure everything looks right. In my opinion, alignment with spaces is the hardest thing to do when developing with a screen reader and it's really hard to avoid when your code convention requires it and you don't have a tool that does it for you.
2. Make error messages textual. A message like error at line 10(25), invalid syntax where 25 is the column is much easier to read than error at line 10, followed by the line with a ^ under the character in column 25. Another thing Python does wrong. 3. If you make a GUI framework, use native controls. Screen readers aren't magical pieces of software that do their things using arcane spells, to read anything, they actually need to get the information to read. To do this, they use operating system APIs. When an application uses native controls, it exposes all the needed information through those APIs and a screen reader can get it easily. If an application has it's own GUI toolkit, it's own representation of controls that doesn't correspond to the OS notions of a control and draws on the screen directly, the screen reader doesn't know anything at all. This is the case with i.e. GTK on windows. For a long time, this was also the case with Flash, Java and QT.
4. screen reader users generally prefer words over symbols (controversial, some might disagree). Symbols are nice for sighted users because they take less space on the screen and are faster to read, but for screen reader users they are not.
Lua's "if a less than 1 then print quote this is a test quote end" reads much more naturally than go's "if a less than 1 left brace fmt dot print l n left paren quote this is a test quote right paren right brace". There's a reason why blind programmers like lua and ruby.
5. Very hard to do right, but one of the most annoying thing for me is to deal with various messages in the console. If it's a web table, you can do two columns, timestamp and message, and a blind user will know it's a table and be able to navigate only in the second column. If it's console output, you can separate them visually, sighted users will just glance over the timestamps but blind users actually need to hear them before hearing the message. Imagine you need to listen through "two tousant eighteen colon eleven colon zero nine seven colon fourty five colon three comma 7520, /cmd/frontend/main.go:19: server started" before each message instead of just "server started". That's the sad reality for most blind people dealing with logs and messages that contain long paths etc. I don't know if that can even be done right without hiding the info alltogether, as it's not possible for a blind person to navigate a table in the console, but this is something that should be taken into consideration. |