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 <p>, <em>, <blockquote>...
”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.
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.
For ca. ten years, the advice was to pointlessly "replace <i> with <em> and <b> with <strong>" 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 <i class="emphasis"> and <i class="media-title"> and <i class="snarky-aside"> etc. than to have added the <em> tag and said "just use it instead of <i>".
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 <p>, <em>, <blockquote>...