Archive: October 30th, 2020

Replying to a tweet from @aardrian

No, no, that was totally down to me reading in haste.

Replying to a tweet from @aardrian

Ah, right, I see now that you said replacing with an actual button is better than adding a role of “button” to a link—that makes sense! So if JavaScript replaces the links with buttons, I may be on my way to covering both scenarios.

Replying to a tweet from @aardrian

Yes, better for screen reader support where the JavaScript executes, but not so good for any situations—screen reader or otherwise—where JavaScript is unavailable (a link would still work as link).

I wish I could handle both scenarios.

Replying to a tweet from @aardrian

If JavaScript add a role of “button” to the link, would that deal with the expectation issue?

(That would still allow the link to be a fallback for non-JS scenarios.)

Replying to a tweet from @aardrian

Yes! As soon as you add preventDefault() to an event listener, you’re signing up to handle all the responsibilities that the browser would usually take care of.

Replying to a tweet from @aardrian

Then make them real pages.

Completely agree with you there!

Big modals that are basically fake web pages—even if coded accessibly—feel deceptive, lacking in material honesty.

Replying to a tweet from @aardrian

If it’s true that screen reader users expect all links to go to a new page, then are regular internal page links (that use IDs) an anti-pattern to be avoided?

e.g. Wikipedia articles with a table of contents. Fragment identifier URLs.