Hacker News new | ask | show | jobs
by onion2k 2291 days ago
I realise it's popular to rally against JS on HN, but in this case the article is about designing a good information hierarchy for users' with sight problems, and the state of accessible design was terrible long before JS apps came along. This is not a JS problem. It's a too-many-developers-don't-care-about-accessibility problem. It's been a problem at least since I started making web software in 1997.

Going back to "design like it's 1999" would present users with things like this - https://web.archive.org/web/19991013122821/http://www.yahoo.... Try finding a link in that mess using a screenreader. You'd be sitting and waiting for it to read them all out for a while. Design was no better for accessibility back then.

The takeaway here is really that when you design a website you need to take an accessibility-first approach. This is a good article to start - https://www.smashingmagazine.com/2018/04/designing-accessibi...

5 comments

The 1999 Yahoo, like the site in the article, is a directory, of course there are going to be a lot of links. The 1999's main flaw is a complete lack of headings (and the "buttons" on either side of the logo are image map links without accessible names).

The site in the article might have overdone it with links, having two links close to each other both going to the same destination, but from the images I think they overdid the number of headings. There are headings that are nothing but film titles and no content following. But the film title headings are heading level 4 so Simon could choose to ignore them and only read the level 2 headings which do seem to be for identifying groups of content within the page.

Simon can use Ctrl-F to look for particular text in the page, same as anyone else, if he's looking for something in particular. If he's just browsing, he's going to have to read all the links until he finds what he wants, same as anyone else. He can't visually skim in two dimensions but his screen reader can read the text much faster than a inexperienced user could understand.

Precisely. I'm one of the few dinosaurs who still works in the non-web software space, and I can say that accessibility is still not where it ought to be in that space, and its problems pre-date the web.
Many of the people here on HN probably work at much larger corporations than I, so my take might be different. But what I have noticed is a severe lack of interest in hiring UI/UX people. Earlier in my career I had access to at least one UX person I could team up with before starting a new app.

There are some great ui libraries you can leverage these days, and they seem to fool some management into thinking pretty equals well designed. Eventually I end up in a series of meetings where we decide the aesthetics by committee. They don't seem to appreciate that a dedicated person could do it faster and better. But they always ignore my request for such a role.

One thing I also notice when seeing issues like this is that this is also a problem with both the assistive tools themselves, and the accessibility APIs and methods available to build web pages.

I don't think there's anything inherently wrong with building content and feature rich websites, but when we do it is difficult to build them in a way, with or without javascript, that's also useful to browse through screen readers. We have to resort to hacks like skip link hacks and the rest.

I think not only do we have to get better at building accessible web pages, but the technology needs to get better to make building accessible web pages easier and more usable.

Skip links are mainly for people who don't use a screen reader but do solely operate the computer by keyboard (or keyboard emulator, like a switch). Screen reader users shouldn't need skip links because page content should be organized within landmarks (header, main, search, footer, etc.) and have headings identifying different parts of the page and their logical hierarchy, the screen reader gives them tools to list and move to those semantic structures.
This is actually one of the exact 'features' I was thinking should be there. I guess this might be due to my inexperience with these tools (my problem!) but I've never experienced, or figure out how to, jump between the landmarks with VoiceOver.
In VoiceOver on a Mac, one way I know is to press VO-U to open the Web Rotor then use the left-right arrow keys to navigate through the options, one will list landmarks if they are present on the page.

I don't recall how to call up the Web Rotor on iOS devices.

Slightly off-topic, not related to accessibility, and maybe it's nostalgia, but seeing that yahoo page from 99, I miss that web. Everything is so easy to see from there. Sure, it looks boring. But it's so functional, for me.
Everything is so easy to see from there.

Yahoo has thousands of categories of links, so you're really only seeing a tiny portion. Finding something niche required drilling down three or four levels (and exploring if you couldn't find the right one.) Google's search box is much more efficient, but you lose the fun of discovery.

That's fine - I would expect to find something niche after doing some research.

Show me an example of "something niche" being available. Right away?

I don't always have something I want to search for, either.