Notes

5707 sparkline

Monday, November 9th, 2020

Replying to a tweet from @kazuhito

I hadn’t planned to. But I think any differences should be relatively minor.

Replying to a tweet from @kazuhito

Oh, that’s fantastic news—a Japanese translation would be wonderful!

I found my original Markdown manuscript files and added them:

https://github.com/adactio/resilientwebdesign/tree/main/markdown

But the HTML will be more up to date.

Saturday, November 7th, 2020

Yub nub!

Friday, November 6th, 2020

Replying to a tweet from @haysstanford

It’s the other way around. I post my notes and replies on my website. A copy gets sent to Twitter (along with a link to the canonical URL).

It’s the same with photos: I syndicate them to Flickr. And blog posts: I syndicate them to Medium.

Replying to a tweet from @haysstanford

Restraint.

Replying to a tweet from @webaxe

Right …except my blog post wasn’t about modal dialogs specifically. It was about all kinds of progressive disclosure.

e.g. A link that pops open a log-in form not in a modal dialog.

Thursday, November 5th, 2020

Replying to a tweet from @jr_roman

Thank you, Julie!

Wednesday, November 4th, 2020

Replying to a tweet from @nonswearyphil

That was badly phrased on my part. I wasn’t trying to say that all keyboard users are a subset of screen reader users, but that screen reader users are often keyboard users.

Saturday, October 31st, 2020

Creepy potato.

Creepy potato.

Friday, 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.

Wednesday, October 28th, 2020

Replying to a tweet from @craigmod

There’s the story of T.E. Lawrence losing the first manuscript of The Seven Pillars Of Wisdom on a train …though it’s more likely that the story is his version of “the dog ate my homework” because he didn’t like what he’d written.

Replying to a tweet from @rem

Well, this is a weird example but look at the output of this XML https://thesession.org/tunes/new?format=xml with and without the extension enabled. With the extension, you can see the JavaScript dumped to the screen.

Replying to a tweet from @rem

Ah, interesting! I had that installed until very recently too: I had to disable it when I discovered it was inserting JavaScript into every response (making debugging very difficult). We should tell the good folks at @DuckDuckGo.