 | | I used a screen reader for a few years due to sight issues, these days I use a screen again with magnification. When you work without a screen you end up having to build up a mental model of the code, which you keep inside your head. When you navigate the code, you are doing it mentally, inside this cathedral you maintain in your mind.So given that, the main challenge for me was code navigation. I used Visual Studio at the time and it allowed me to jump to method definitions, call references, jump to the start/end of a method etc. So the worst thing was long methods as 1) I had no efficient way of navigating them except to read each line 2) it was hard to keep track of all the things the method did. Breaking up code into smaller pieces with good naming of each method helped speed up my understanding and navigation of the code a lot. It also simplified the mental model in my mind. |
|
| | As a person who can visually see, I want to emphasize that these goals: short methods (max 40 LOCs) and speaking names for all code entities are equally important to me. I want to spend as few time as possible reading the code. I want to spend most time on modifying and transforming the code. I do so by building up a mental model which I can change freely before typing the changes down. Sometimes it helps to write down the ideas to see how they "look like", however everything you say applies equally well to me as a non-blind programmer.Another important trait of easy to read code is the rule of "Big picture" first. I.e. if you have a `main()` method you will find it first in my files, only then followed by sub methods which are called by main(). Same holds for types: first comes the class and then it's followed by any type which might be required for a class attribute. So, when opening a file you immediately get the big picture and depending on the granularity you want to build for your mental model you can continue reading by scrolling down. When the model is good enough, you can skip the rest of the file. I find this pattern to the contrary of how others design their files. There are people who list all details and sub methods first before telling me only further down the road how these details are put together. This forces me to read a lot of code to build a blown up mental model which might not be necessary for the current task at hand. |
|
| | I've just written a little parser I OCaml, and the file goes like this: Module declarations ( 3 lines) Parser type declaration ( 1 line ) Implementation details you don't care about (47 lines) Actual grammar (20 lines)
In that order. In Haskell, I would probably have put the grammar at the top of the file, so you can get the big picture right away. But the language reads stuff from top to bottom, so I have to put the big picture at the bottom. An alternative would be separate the details from the grammar, but then I would expose those implementation details in an interface, while in fact the rest of the program is only interested in one function that parses everything. Or, you could write from bottom to top. It's OCaml, so you know the big picture cannot be at the top. Now a case could be made for a language that reads toplevel statements from bottom to top… |
|
| | To be fair, C is kind of like that, too. You could move the declarations of static functions to the top, but then you'd still have declarations that prevent you from getting to the real meat. |
|
| | > When you work without a screen you end up having to build up a mental model of the code, which you keep inside your head. When you navigate the code, you are doing it mentally, inside this cathedral you maintain in your mind.Interesting! I am not visually impaired (not beyond what can be fixed with reading glasses), but I have always worked like that with code. |
|
| | To get some perspective on the difficulty of building this model, imagine you can see fine, but your screen can only display one word (token) at a time. You can navigate with arrow keys and a list of keyboard short-cuts.This restriction applies to whether you are coding, browsing the web (on Stack Overflow), reading XML (shudder). So the importance of a mental model is critical, because without maintaining context of where you are, you can get lost and spend too much time rediscovering your surroundings. The better your model the faster you can navigate and the less effort required in general. |
|
|
| | There has been a very interesting discussion, that is not 100% equal but where you can get comments about similar problems, including some from blind programmer. I hope they may be helpful."Ask HN: How should a programming language accommodate disabled programmers?" https://news.ycombinator.com/item?id=18414562 (164 points | 8 days ago | 116 comments) |
|
| | Thanks! That's really helpful 🙂 |
|
|
| | To pile on here on a (vaugely) related tangent, Common Voice (from Mozilla) needs our help to build a public speech corpus for training speech recognition software and Text to Speech: https://voice.mozilla.org/Mozilla is currently hard at work on DeepSpeech for transcription and Text to Speech, which could be huge for accessibility. I hope it continues to improve 😛 |
|
| | One very specific thing I remember from discussions I had with a blind programmer was to use of multi-line comments (/* /) in favour of line-comments (//), especially for comments that do span multiple lines.That helps a lot because with a screen reader “slash star <comment text> star slash” is significantly more listenable to when compared to “slash slash <one line> slash slash <another line> slash slash <third line>…” Surprisingly this is the only thing I cannot seem to find around my IRC logs… Digging through the logs other things that were called out to make comprehension harder for blind people are: * Unicode identifiers; * Boilerplate you cannot easily skip past without losing context (common in e.g. Java); * Typos (esp. if done on purpose, inconsistently); All this comes from their preferred interface being a screen reader which, I believe, is true for most blind programmers. |
|
| | Screen readers should be made more context aware. The IDE knows what's a comment, the screen reader should know that as well: "comment <comment text> end comment" or something.This may be even more important for the rest of the code. Who cares about the parentheses after the `if` keyword? No one, they're just there to delimit the condition. Likewise the curly braces, they just delimit a sub-block. Their absence should not stop the screen reader from spotting the end of the `if` block. They should say "end if" regardless. Same goes for Python. Structural editors have mostly failed, but maybe some specialised version could be more useful to blind people? |
|
| | Who does inconsistent typos on purpose? And what's the purpose? |
|
| | Some people use the archaic spelling "shew" but only the senses "to prove or demonstrate". Or again in mathematics "rng" to mean a ring that does not necessarily have an identity. Or "iff" to mean "if and only if". These would look like inconsistent typos to nonmathematicians.Or "referer" in HTTP because that's what the standard uses. Or "creat" when discussing the UNIX system call or a function with the same purpose on another platform. |
|
| | I am not blind but I have shitty sight and I wish web browsers do the same thing they are doing now with http sites an deny access to web pages with light grey text over nuclear white background. |
|
| | I do not think you need to deny access (although I think that if the webpage doesn't need colours, it shouldn't set any at all, instead using the user's preferences), but (as defanor mentioned) you can apply CSS (although it doesn't have to be global; I generally apply user CSS individually instead, since each webpage needs a different CSS to be fixed; usually webpages that don't already have CSS don't need any CSS to fix them, I find, though) |
|
| | A global [dark] CSS theme helps to deal with that. Setting display brightness to minimum and increasing contrast can help to mitigate it, too. |
|
|
| | If you know any visually impaired programmers, please share this with them! |
|
