It would be so much fun to make replicas of his art on the "Etch A Sketch" [1].

[1] https://en.wikipedia.org/wiki/Etch_A_Sketch

I wonder how his art would have been affected if he'd had access to an Etch-A-Sketch?

I wonder, did anyone ever make one of those with an "erase" button?

The particles are aluminium. That isn’t ferromagnetic, but its conductivity is good, so you can induce eddy currents in the particles.

That hints at a totally impractical way to do that with regular etch a sketch: put a strong magnet on top of the screen wherever you want the image to be retained and flip over the device.

Where you put magnets, eddy currents will be induced into the aluminium dust. Those will generate a magnetic field that slows down the particles, as they drop towards the screen.

So, if wait just long enough, and flip the device back, you can prevent those particles from reaching the screen.

Problems/challenges:

- “just long enough” will be very tricky to accomplish

- you probably will need very strong magnets

- it will be a challenge to have well-defined regions where your magnet(s) don’t affect the screen

⇒ I guess it may be easier (not easy) to cool your etch a sketch to -196 °C and use a strong magnet (https://youtu.be/zU3niMdjegQ?feature=shared)

Easiest probably would be https://hackaday.com/2024/03/27/sort-of-electromagnet-attrac... (likely still impractical for the distance needed in an etch a sketch)

Thanks for that wonderful exploration of the problem space.

Side note on magnets: when our kids were young, I got one of theose stick-and-ball magnetic sets that are capable of making geometric figures. So I made a Archimedian-style polyhedron big enough to be a helmet. I wore it for some minutes on a few occasions and it gave me a very unpleasant (but subtle) headache and a deep, somewhat lasting nausea.

I try not to put magnets near my body anymore, nor allow the kids to. My understanding is that our bodies were evolved over millennia without being near magnets (or electric fields), especially the neodynium sorts.

Anyhow, thanks for the thoughtful reply. It's the best of the internet's potential.

I am glad to see a happy user here! :)

I am super glad you like it! The primary reason I haven't introduced support for iframes is that it requires much wider permissions (instead of just access to the current tab after clicking the "ARIA DevTools" icon you'd need to grant access to all data on every website you visit). I will research if things changed since I last checked, though.

Is there a chance to get a link to the page? I'd love to try it out and fix.

I can't link the page, but this is a cleaned up DOM output (the extra spans/divs are components):

`<div><div><span aria-label="IMDb rating" title="IMDb rating">IMDb 8.2</span></div><div><span aria-label="Parental guidance" title="Parental guidance">12+</span></div><div><span aria-label="Production year" title="Production year">2007</span></div><ul aria-label="Genre"><li><div><span>Romance</span></div><li><div><span>Comedy</span></div></ul></div><section><div><h2 id=":r1j:-cast">Cast:</h2><ul aria-labelledby=":r1j:-cast"><li><span>ABC</span><li><span>DEF</span><li><span>GHI</span></ul></div></section>`

`section ul { margin: 0; padding: 0; list-style: none; li { display: inline; &:not(:first-child)::before { content: ", " / ""; } } }`

Adding a name to an element without a role, like span or div, is technically invalid; in this example, only the <ul> elements have valid names added to them, because they implicitly have the role of "list."

Also, aria-label and aria-labelledby replace the contents of an element when the contents would otherwise be the name; if the <span> elements where <p> instead (which has an implicit role), screen readers would only read "IMDb rating" and not "IMDb 8.2."

What might be happening is the aria-label attributes are ignored but the title attributes are used as a description after the contents. For some elements `title` can be used as an element description; I think descriptions are also invalid without a role but they may get used anyway.

I think it's best for a visualizing tool to not display attribute information that won't be used by screen readers.

That's some good feedback and I honestly think this should have been an definition list from the start.

I was interested about how it would change if I replaced those `span` with `p` and it still reads the entire block for me with VoiceOver.

- Parental guidance, group

- [arrow right]

- end of, Parental guidance, group

- [arrow right]

- 14+

- [arrow right]

- Production Year, group

- …

When I look at the Chrome Accessibility Tree it shows

heading "Tags"

  paragraph "Parental guidance"

    StaticText "14+"

  paragraph "Production year"

    StaticText "2016"

When I revert back to the span the `paragraph` is replaced by `generic`. I only have hands on experience with VO so I imagine that JAWS/NVDA might yield different results.

I do believe you're right that this shouldn't be a `aria-label` and I will replace it with `aria-description`, but I don't think that we can say that `aria-label` should only be used to fully replace the contents, as a landmark container would also be named by aria-label: https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/...

Edit: I just tested this but `aria-description` is not read at all. And https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... seems to indicate that aria-label should still be ok, but the div does have a `role="application"`

Be aware that the vast majority of people who rely on VoiceOver use Safari as their browser; on mobile devices, they have no choice. There are some ways in which Chrome for Mac does a better job of managing its accessibility tree than Safari but there are a bunch of other issues.

Accessible Name and Description Computation is complicated, some elements can get their name from their contents and some can't; frankly, I can't keep it all straight in my head.

https://www.w3.org/TR/accname-1.2/

Additionally, there's what the specs say and what browsers and screen readers actually do.

VoiceOver doesn't support the `aria-description` attribute yet. The `title` attribute is often computed as an element's description, when it's not computed as its name (it's not a good choice for naming elements, except <iframe>).

https://a11ysupport.io/tech/aria/aria-description_attribute

`role="application"` isn't a good role for static content and should only be used when letting a screen reader used its keyboard shortcuts would interfere with the user operating interactive controls (which should rarely be the case).

https://www.w3.org/TR/wai-aria-1.2/#application

Don’t get me wrong, I was just making an observation about a ‘role’ being specified. Not suggesting the role=“application” should be used here.

Ultimately in my case I’m leaning to either replacing the production year, parental guidance and IMDb rating with a dl or prepending sr-only titles to the individual tags.

I tested the page with VO on Safari and got the same results as on Chrome. So the good thing is that in practice the current setup appears to be accessible, but it’s frustrating that the theory seems to be different and just not clearly defined.

That's super helpful. I will get this fixed soon :)

When I designed the tool I've tried to mirror the experience of screen readers users instead of only displaying ARIA roles and properties.

For example you have to navigate the page with your keyboard only. If a dropdown isn't accessible - it's instantly clear for the user. Another example are tables. They present only one cell + their headers at the time. I think it's super close to the actual experience of screen reader users.

Thank you! I really think there's a lot of potential in ARIA DevTools. It's quite popular (at least for my standards) but I never had any connection with people that live and breathe web accessibility. And the devil is in the details here so to be fully fair, WAVE is most probably more accurate.

Definitely more accurate however it's UX is awful and doesn't do a good job of prioritizing issues. It sucks that you basically have to install a screen reader app to get the most accurate idea of how screen readers see your site.

I am creating custom hardware for my own SaaS. So far I've designed a custom 3D printed case and wrote early version of firmware.

It feels great to create something physical after over 10 years of working on CRUD web apps.

My work is open source and available at https://github.com/ziolko/eink-calendar-display.

this is really nice

Thank you! I hope to see it used in some office in my hometown soon :)

So glad that people find my little project useful!

Please keep in mind that you can always post your improvement ideas or PR's here https://github.com/ziolko/spreadapi.

Last year I've configured a simple ssh + Caddy based ngrok alternative and it works beautifully every since. I've shared instructions on https://github.com/ziolko/tunnel for anyone interested.

You can easily turn a spreadsheet into a small CRUD database with HTTP API using Google Apps Script. I've shared an example a few years ago: https://spreadapi.roombelt.com/setup.

How's the performance?

Good enough