Hacker News Reader

Comment by Philadelphia | Hacker News Reader

How is javascript required for accessibility? I wasn’t aware of that.

It is not. In fact, it is all the modern design sensibilities and front-end frameworks that make it nearly impossible to make accessible things.

We once had the rule HTML should be purely semantic and all styling should be in CSS. It was brilliant, even though not everything looked as fancy as today.

JS is in fact required for AA level compliance in some cases, usually to retain/move focus appropriately, or to provide expected keyboard controls.

https://www.w3.org/WAI/WCAG22/Techniques/#client-side-script

Also, when was that semantic HTML rule? You make it sound like ancient history, but semantic HTML has only been a thing since HTML5 (2008).

You only need to use scripts to move focus and provide keyboard controls if you have done something to mess with the focus and break the standard browser keyboard controls.

If you're using HTML/CSS sensibly then it's accessible from the get-go by dint of the browser being accessible.

> Also, when was that semantic HTML rule? You make it sound like ancient history, but semantic HTML has only been a thing since HTML5 (2008).

HTML5 added a million new tags, but HTML4 had plenty of semantic tags that people regularly ignored and replaced with <div>, for example , , <blockquote>...

IMO is a terrible example.

For ca. ten years, the advice was to pointlessly "replace with and with " and it utterly screwed over most new web developers' understanding of semantic tags. There are many reasons to use italics (and they vary between languages) but "emphasis" is just one of them, and none of the others ever materialized as tags.

It would have been far better to have recommended and and etc. than to have added the tag and said "just use it instead of ".

”You only need to use scripts to move focus and provide keyboard controls if you have done something to mess with the focus and break the standard browser keyboard controls.”

That is straight up untrue. Some ARIA patterns require developers to implement focus management and keyboard access from scratch.

For example, ”Correct implementation of the tree role requires implementation of complex functionality that is not needed for typical site navigation that is styled to look like a tree with expandable sections.”

But sometimes you do need that kind of widget for something else.

https://www.w3.org/WAI/ARIA/apg/patterns/treeview/

Sorry, I completely forgot about the existing semantic tree view element that exists and can be interacted with visually but doesn't provide any accessibility or keyboard support because the browser manufacturers decided to skip that one.

Or are you talking about a situation where the developer has implemented a custom component (aka "done something") which doesn't use the native focus system and therefore requires additional work to make accessible?

If by ”done something” you mean the devs made custom widgets have the proper ARIA roles so they’re usable for people who use a keyboard to navigate, or who need screen readers and their plethora of different navigation modes. This is usually the case when a suitable standard component does not exist or is not well supported across browsers. Hierarchical tri-state checkboxes come to mind.

The native focus system typically works just fine, but JS is needed for keyboard interactions and to set things like aria-activedescendant.

In some cases, sure.

I'm not saying the ideal frontend dev writes no JS. I'm saying they write as little as possible. Some times you need JS, nothing wrong with that. The vast majority of the time you don't. And if you do I'd say it's a self-imposed requirement (or a direct/indirect result of a self imposed requirement) most of the time.

Recently I took a little dive into making some pages, that have fallback for when the user doesn't run JS. Those pages are polling an API and displaying updated status. I made sure the pages can be reloaded and show updated status information, and telling the user, that they can simply refresh the page to get that updated information, but only showing that hint about reloading, when they do not run JS. Thus I built a workflow, that people can use whether or not they run JS. I did that, because I think it is the right thing, and because I often preach, that most sites should work without JS.

For me as a mostly backend dev, this was actually quite easy to achieve. Tiny modification of the backend API, some work in the frontend using JS to remove hints that should not show when JS is running, and voila, it works. Of course my pages are very simple in nature, but the same principles can be applied to larger pages. One could even link/direct to different pages, depending on the user running JS or not, and then have a workflow without JS and one with JS. It is all possible and only a matter of wanting to make an effort. Of course, modern JS frameworks do not really encourage this kind of design. Though server side rendering becomes more popular these days, I don't think we are quite there yet.

A page that is blank when not running JS has exactly zero accessibility.

The web standards project was founded in 1998.

https://www.webstandards.org/about/index.html

Some of those are fixes for misbehaving javascript like disabling nonessential alerts, stopping blinking, reducing animation; some are antipatterns like opening new windows, changing link text, colors, scrolling.

Reply on news.ycombinator.com