Hacker News Reader

Comment by bertjk | Hacker News Reader

Have you ever encountered any web sites that you feel went above and beyond in accessibility? I have sometimes wondered while debugging a site for accessibility concerns, fixing the nth input focus problem or what not, whether it would be preferable to actually just design an entirely separate optimized audible experience instead of forcing the user to infer the shape of a designed-for-sighted people website by tabbing all over the place. I imagine that a working implementation would roughly resemble a keyboard navigable phone menu, with the main point being that it would not necessarily correspond to the visual design, but would still offer all of the functionality expected and probably in a more efficient way. Is this a thing? Should it be a thing?

View on HN

I think one problem with that approach is that blindness isn’t binary. Many registered blind people are partially sighted and use screen readers and other assistive tech to supplement low vision.

Another concern: as someone working on a large web development team, I think that maintaining a separate “non-visual” site would entrench a two-tier approach to quality and completeness (noticing and fixing issues, adding new features, etc). If you treat them as two separate applications they will inevitably diverge over time, despite best intentions. You might even end up with slightly different URL structures on each site, making it impossible for a blind user to find the corresponding audio version of a certain URL they found on social media, for example.

It seems to me that if this ruling is enforced and becomes accepted we may see a welcome move towards 'accessibility first' design - which would be an interesting paradigm shift for many devs.

I would welcome 'accessibility first' if it means people start thinking about 'semantics' again. 10-15 years ago, the web dev world was obsessed with semantics, separation of style and content, the idea you could just edit CSS to do a complete redesign (like csszengarden.com), and your markup could remain untouched, understandable by all devices present and future. I think this notion still holds some power, but it's obviously taken a hit with the component paradigm. The modern approach of 'sprinkle-on' accessibility doesn't work as well, and just feels like a messy extra step you have to do when building a feature. It was much better when people cared about baking it in from the ground up, through considered semantics and document outlines.

> it's obviously taken a hit with the component paradigm

Can you please explain how the component paradigm is at odds with semantic markup? Is it just that developers are now satisfied with the semantics being in their component names and props, and don't care if it actually gets rendered as undifferentiated divs?

My own hypothesis is that React gave developers permission to question some things that were previously deemed sacred in web development, and developers went too far with that. Using a component framework like React or Vue is not inherently at odds with producing good semantic markup.

> Is it just that developers are now satisfied with the semantics being in their component names and props, and don't care if it actually gets rendered as undifferentiated divs?

Basically, yes. Also, components often require extra div-nesting for robustness, and then there's the obfuscated classnames (CSS-in-JS), and the way responsiveness tends to be done these days (crude media query helper components that show/hide duplicated subsections of DOM for different devices). This all means the rendered DOM in devtools is bloated and hard to read anyway, so there's less point in caring about keeping it nice and clean.

Also, if you're mostly focused on building individual components, you probably don't feel as much ownership over the page as a whole, so you don't think about how your rendered DOM affects the document outline. Without that bigger picture, semantics isn't as interesting.

That kind of markup may also be useful for software analysis. Parsing prose is becoming tractable. Maybe Alexa or the (nameless) Google Assistant will be able to order the pizza for you. They're supposed to be able to do it over the phone.

Popular web design frameworks like Bootstrap consider accessibility and encourage it in their documentation. See: https://getbootstrap.com/docs/4.3/getting-started/accessibil...

Are there any accessibility-first web design frameworks?

I think the United States Web Design System might fit in that category. It's made by the US Digital Services, and describes itself as "A design system for the federal government. We make it easier to build accessible, mobile-friendly government websites for the American public."

It's a well thought-out framework and from what I've read, accessibility was taken into account in the very first stage of the redesign of the new V2

https://designsystem.digital.gov/

Totally free since it's paid for with US tax dollars.

This approach doesn't work. It has been tried in the past, and almost always produced the same result. The alternative version is not maintained, and after a while you end up with just a small selection of features to be useable for those which use the specially designed version. It will go out of sync, or the specially designed version will never get updated. This is the best way to create a ghetto.

Microsoft does a TON of work to make it's applications not only accessible, but user friendly to screenreader and keyboard users.

This is most obvious in the OneDrive online. The selectable list of files is implemented using Layout Grid, and thus is a single tab stop. Arrow keys can be used to navigate the grid and inline actions, and it's a single SHIFT-TAB to navigate up to the multi-selection actions.

There's ARIA controls and interactions that are defined in such a way that a non-sighted user can just hear what "type" of interaction it is and already know how to navigate it.

Reply on news.ycombinator.com