Hacker News Reader

Comment by miki123211 | Hacker News Reader

The written word is (kind of) the impressive part. The spelling rules of English are not easy to master, and blind people have much fewer reading opportunities than the sighted. You don't see labels on the products you buy, you don't see the billboards from a passing car, you often don't even read books or articles, as listening to synthesized speech is much faster, cheaper and more comfortable than reading Braille.

The only reason my spelling is as good as it is is the fact that I used to listen to English text with a Polish speech synthesizer for most of my life, as I was too lazy to switch languages. Polish is (almost) phonetically perfect, so I was hearing things almost exactly as they were written. This made my spelling much better than that of most blind Americans. Words like cystom (system), keybored or even polotission (politician) can sometimes be seen in the blind community.

View on HN

>sometimes be seen in the blind community.

HAH! Love it. Side note: I constantly make fun of the English phrase "I see what you're saying", meaning "I understand", often swapping it out with "I hear what you're seeing", sometimes swapping it multiple times in one sentence. People almost never notice unless I follow it up with "I smell what you're feeling" or "taste what you're smelling", because this creeps them out.

Funny anecdote : A software engineer teammate and I were discussing a change IRL in office standing next to my desk, when there was a churning sound from his stomach (the things we miss WFH). It was not too loud, but loud enough to derail my speech - Instead of saying "<my lengthy explanation..> <stomach_sound> Do you see that?" as a substitute for "Do you see what I am saying?", I accidentally said ".. Do you hear that?". SO awkward and funny

Interestingly in the Netherlands they do express things via taste words. Lekker (meaning tasty) can describe an experience, doing something well and more.

Heerlijk (meaning delicious) can also be used. I found a gravestone with the translation: “we thank you God for your great deliciousness”.

Not quite - "heerlijk" used to mean "lordly", so "heerlijk voedsel" means "food eaten by lords". This also explains the gravestone reference (de Heer == the Lord).

Thanks for clarification! Good to know. I often find it hard to learn and retain the multiple meanings / history of words in a second language. I do know de Heer, and Herengracht etc. I just hadn’t put that together that it’s same origin.

This is also common in other languages. Indonesians use enak (tasty) for almost any positive quality. Even in English people refer to attractive members of the opposite sex as "tasty"

But "heer" in Dutch is either a (human) lord or God, so "heerlijk" means lordly or godly, and over time this became more general.

Much the same word exists in German, "herrlich", but it means "beautiful" or "splendid". Same idea though.

I've mostly referred to members of the same sex as tasty, myself.

These words have shifted similarly but subtly differently in Norwegian too. Lekker = lekker, heerlijk = herlig.

That last example is wrong as translated.

In that context 'heerlijkheid' has nothing to do with taste words, it simply means 'glory'.

Off topic and feel free to ignore but here goes: do you know of any low hanging fruit stuff I can do on web/front-end UIs that will help me get my sites/apps more accessible, that many developers miss? And secondly, do you know of a way to quickly simulate the experience a visually impaired person has without learning/using a screen reader? (As a solo developer, I don't have the time to dive too deep)

If you're on a mac of course the easiest screenreader to use is voiceover, if on windows NVDA - problem there is not wide consensus among screenreaders about functionality, so you will read about a way to do something and think that is the way to do this but when you actually start doing it you find it isn't going to work the way you thought, if at all.

This means if you do anything good you will need to test on different screenreaders, I like https://assistivlabs.com/ for a service to allow you to do screenreader testing also because the developer who runs it is really helpful.

It also means the best ways of doing things tend to be the ones that have been around longest because every screenreader / browser combo has implemented different parts of newer specifications - that is to say it will feel like your chosen screenreader is Chrome, but all the other ones are IE11.

I personally find that what helps you most about understanding when a site is not accessible enough is, after you have read a bit about problems people with screenreaders have, imagine using your site if you were blind.

Because you are blind things happen atomically, you do not have an context clues that you can see about what something is, so actions you can do on stuff should probably say not just what they are doing - like a button that says Delete - but what they are doing it to - like a button that says Delete and has an aria-label that says Delete user account. Really - being willing to sit still for 20 minutes looking at your site and thinking but what if I couldn't see will probably help you find a bunch of obvious problems.

Also when you have a sort of good fundament to your sites assistive usage, it means that things will be a lot easier when you do start testing on different screen readers.

on edit: obviously when I say because you are blind things happen atomically, I mean that in the context of using a screen reader on a webpage

> Really - being willing to sit still for 20 minutes looking at your site and thinking but what if I couldn't see will probably help you find a bunch of obvious problems.

Yes, I'm hoping to acquire this mindset. What I'm building is quite simple, almost crud like in terms of the UI. The issue is I don't feel I get the mindset just yet. I understand speech is linear, and I assume the order mainly comes from how it's laid out in html (as opposed to position). But how do visually impaired navigate the items in this big list, intuitively and quickly? I assume focusable elements are critical, but how about the the rest of the content hierarchy? A row in a table doesn't tell me anything if I can't see the header simultaneously - for instance.

if your table should be a table and is correctly coded as a table pretty much every screen reader will make it usable, in this example

https://www.w3.org/TR/wai-aria-practices/examples/table/tabl...

using voiceover you read the table it tells you the column names, probably in reading a table you would probably first read all the headers so you know what the table is dealing with - here these are first name, last name, company, address.

If you know what value in the table you are looking for you would go to that column, for example last name the second column, then navigate down with the voiceover key combination and the down arrow to get to the row you are interested in - row 2 James I'm looking for sara james so let's go to the first name column, then you could use voice over key combination and left arrow to go to the first name column and see it is Sara, then you read all the contents of that row to find out Sara James, Acme, Inc., 123 Broad St.

Obviously you need to remember the headers in this way of working, so if your tables are really complicated and have a lot of data in each column it might be nice to put a hidden screenreader only message in there that says Contents for First Name Column or something like that. But in this simple case I think it is reasonable to assume people will remember the column headers.

on edit: this is from a developer who is not blind however, so a blind user may have more efficient ways of working than me. Also note, many screen reader users are not completely blind or have some other disability, like dyslexia, which makes using a screen reader useful for them. A dyslexic user may be able to figure out the headers of the table, but if the individual cells have a lot of content the screen reader will be useful for them.

Add Pa11y to your CI: https://github.com/pa11y/pa11y

Another good resource is the GDS accessibility standards: https://www.gov.uk/guidance/guidance-and-tools-for-digital-a...

It's tailored towards creating services within the GDS portfolio of services but there is good advice in there too

Absolutely. One is dead easy, quick, and free.

Step 1: Use a desktop PC. Step 2: Unplug your mouse.

Now learn to use your computer and then your site.

Windows is basically 100% usable by keyboard alone, and that basically is how all blind users use it. They can't see a pointer so pointing devices are useless.

I am Very Old™ and I learned Windows in the 1980s in a company that sold Macs as well as PCs, so it didn't have any PC mice. So I learned to use Windows with keyboard only.

I still can, although it's harder now. But I now run mostly MacOS and Linux.

Windows works very well with the keyboard and I sometimes amaze people by how fast I can move around and do stuff, because I don't take my hands off the keyboard or point and click much. I use the keyboard to run programs, move and rearrange windows, close windows, select and copy and paste, navigate forms etc.

All standards-compliant Windows programs use the same keystrokes to do this and they work everywhere. Learn them and you'll become faster anyway, _as well_ as improving the accessibility of your sites by becoming familiar with how blind users must access them.

> Off topic and feel free to ignore but here goes: do you know of any low hanging fruit stuff I can do on web/front-end UIs that will help me get my sites/apps more accessible, that many developers miss?

Not sure if many developers miss this:

Look at your UI in black/white. Plenty of folks are colour-blind of one kind or another. If your UI works in black/white, it'll probably work for any kind of colour-blindness.

See also https://www.youtube.com/watch?v=-IhQl1CBj9U for something focused on games, but with broader applicability.

Take with a grain of alt b/c I'm not blind and my accessibility training is not formal, just learned from a job.

The built in mobile screen readers are not hard to setup. Enable in the settings and you can play around with it to grok how it works and how to navigate the UI tree with it.

Lowest hanging fruit always seemed to be making sure all the controls you wanted on your page were reachable with accessibility navigation (ie tabindex/focusable) and that the spoken labels were sufficient without sighted context.

So, you are not even a native English speaker then? Oof. You have my respect.

It's really common for educated non-native speakers to spell better than native speakers. Because non-natives learn the language already with a written support, so they have worse pronunciation but better spelling compared to people who learn the language exclusively orally as kids.

My partner is a native speaker and I'm not, yet he often asks me how to spell.

That is super interesting! Thanks for sharing

this reply articulates what I was trying to say.

Makes me wonder if for blind people forms of phonetic typing would be more useful.

Like chord keyboards.

Or maybe some other less wide spread but also less complex to use phonetic input methods?

Absolutely incredible. Thank you for sharing this.

In programming, it's important to structure correctly, format correctly, and spell consistently. This might explain why.

Reply on news.ycombinator.com