@aardrian@toot.cafe
@aardrian@toot.cafe avatar

aardrian

@aardrian@toot.cafe

One hoopy frood who really knows where his towel is.

Searchable on tootfinder: https://tootfinder.ch/

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Chris, to accessibility
@Chris@mastodon.social avatar

I'm stuck on an question, if anybody has any concrete advice.

I have a background video. According to WCAG 2.2…

  • SC 2.2.2 indicates that there should be a means to pause moving, blinking, scrolling, or auto-updating information

  • SC 1.2.1 indicates that there should be an alternative or audio for video

Assuming the only "information" in the video is just vibe setting, is anything really required here beyond a text description? Am I missing anything?

aardrian,
@aardrian@toot.cafe avatar

@cwilcox808 @Chris
The challenge here is that a sighted screen reader user needs access to the stop button. Which means it has to be exposed. Which means a blind screen reader user will then know something is playing. Which means they will rightly think the thing has no alternative. Which means you will then need an alternative.

aardrian, (edited )
@aardrian@toot.cafe avatar

@Chris
An accDesc is announced as a flat string of text, and not easy to re-read, navigate, select.

Probably a disclosure widget (details/summary for in-page search support) adjacent to the video.

But it depends on content, context, expectation, etc.

@cwilcox808

siblingpastry, (edited ) to keyboard
@siblingpastry@mastodon.world avatar

I've been playing around with keyboard scrolling of overflow regions, and I was interested to note how Firefox's native behavior doesn't expose any additional semantics -- i.e., it doesn't apply a role or accessible name when the scrolling region becomes focusable.

And I think that's the right thing to do -- that our standard workaround of including role="region" and aria-label or aria-labelledby (along with tabindex="0") creates unnecessary verbosity.

(1/3)

aardrian,
@aardrian@toot.cafe avatar

@siblingpastry I think I don’t have time to look RN but really want to try it. Especially since, as you note, the model for which I advocate is verbose AF and Chrome keeps rolling back its effort and Safari is ignoring it completely.

peterreeves, to accessibility
@peterreeves@mstdn.social avatar

It's always so frustrating when all the web accessibility content only talks about text heavy websites and forms. Like yes, I get it, I should have alt text on images. But there's so little information about how to build accessible web apps. What do I do if 80% of my page is a WebGL canvas and the other 20% is all buttons/sliders? How do I structure this if there is basically no "regular text" on the entire page?

aardrian,
@aardrian@toot.cafe avatar

@peterreeves Buttons and sliders have guidance (accNames, input modalities). As does page structure (regions, landmarks, grouping contexts). The curveball is the canvas, and if it is strictly a visualization tool, you’ll need to consider things like contrast, use of color, scaling.

But if you are looking for pre-built patterns that tell you exactly how to build a new and novel UI, well, unlikely.

If you were simply venting, then never mind me.

aardrian,
@aardrian@toot.cafe avatar

@peterreeves A big reason you have to wade through so much intro cruft is because a lot of folks (including practitioners) don’t know much beyond that (if that, even). UIs move faster than the patterns, and host platforms impose some limits.

But yeah, I would also love to see a ground-up build course. The catch, of course, is that even those platforms get it wrong in a lot of ways, so that would be a big lift to write (assuming a client didn’t already pay for one and NDA it).

brucelawson, to random
@brucelawson@vivaldi.net avatar

Book review: Prophet's Song by Paul Lynch https://brucelawson.co.uk/2024/book-review-prophets-song-by-paul-lynch/

aardrian,
@aardrian@toot.cafe avatar

@brucelawson When you first posted I thought it might be annoying, but yeah, that is downright frustrating.

aardrian, to accessibility
@aardrian@toot.cafe avatar

Re-filed a Chrome bug that was closed because the reviewer confused <abbr> for abbr:

abbr attribute (not element) not exposed to users
https://issues.chromium.org/issues/342194492

Mostly I want to use <th abbr> to spec. The attached video demonstrates a common use case.

Just rolling that windwill up a hill.

JAWS with Chrome navigating a calendar table where each column header is an abbreviated weekday name.

goulet, to webdev
@goulet@techhub.social avatar

Should I use ::after pseudo-element to add a sort order indicator?

It feels like it's not very accessible because the semantic HTML content doesn't actual contain the sort indicator... but the way I'm conditionally adding it is by reading the aria-sort attribute so maybe that's the accessible part of things and the ::after content doesn't need to be SR-friendly 🤷

<th aria-sort="ascending">  
 <button>Name</button>  
</th>

<style>  
 th[aria-sort="ascending"] > button::after {  
 content: '▼';  
 }  
</style>

aardrian,
@aardrian@toot.cafe avatar

@goulet Do you know that character announces?

I have suggestions:
https://adrianroselli.com/2021/04/sortable-table-columns.html

aardrian,
@aardrian@toot.cafe avatar

@goulet Also, my question was not meant to be a trick question. If you don’t know, NVDA / Firefox announces it as “filled down pointing triangle”, which is really verbose.

aardrian,
@aardrian@toot.cafe avatar

@Lukew
Still nope:
https://adrianroselli.com/2020/10/alternative-text-for-css-generated-content.html#Takeaway-3 (anchor link)

@goulet

aardrian,
@aardrian@toot.cafe avatar

@Lukew
No, you don’t want it announced.

But adding that hides the entire glyph in some cases.

And the glyph is too verbose to use as-is.

So the aria-sort is for SR users, but the glyph makes a worse experience for them on top of that.

I have a pattern here: https://adrianroselli.com/2021/04/sortable-table-columns.html

@goulet

aardrian,
@aardrian@toot.cafe avatar

@Lukew
Did you read my post?

My short answer is probably not, no.

@goulet

aardrian, to accessibility
@aardrian@toot.cafe avatar

Folks.

I am once again a bronze supporter of Inclusive Design 24.

I want to see all of you presenting cool stuff (and making me look good as a result), but you won’t get that chance if you don’t submit before 7 June.
https://inclusivedesign24.org/2024/

Prior years are up there if you want to see the range of talks that have been accepted in the past.

aardrian, to accessibility
@aardrian@toot.cafe avatar

Chrome / TalkBack bug I first reported in 2020, and which was fixed for a time (?) appears to be back. Looking for confirmation before I file yet another one.

A named region with a tabindex does not expose its contents. Chrome / TalkBack only announces its accName and role.

I think I have an ugly workaround (“Shawarma” heading).

Test case:
https://codepen.io/aardrian/pen/ExzyadL

Similar to issue I filed earlier this month, which I limited to APG tab panels.

aardrian,
@aardrian@toot.cafe avatar

@mayank Thanks. Does the “Shawarma” example work well enough?

aardrian,
@aardrian@toot.cafe avatar

@mayank Agreed. Not at all ideal.

Thanks!

aardrian,
@aardrian@toot.cafe avatar

@pkra Yeah, also not a daily SR user. But the confirmation helps. Thanks!

aardrian,
@aardrian@toot.cafe avatar

Got enough confirmation. Filed a Chromium bug:

Named regions with tabindex hide content from TalkBack
https://issues.chromium.org/issues/342172183

Thanks all!

aardrian,
@aardrian@toot.cafe avatar

@pkra Can you tell me the Chrome and TalkBack versions? The Chromium tester is unable to reproduce the issue and I want to be able to cite a spread of independent tests / configs.

aardrian,
@aardrian@toot.cafe avatar

@mayank Can you tell me the Chrome and TalkBack versions along with the phone model? The Chromium tester is unable to reproduce the issue and I want to be able to cite a spread of independent tests / configs.

aardrian,
@aardrian@toot.cafe avatar

@pkra Oh, and Android version.

aardrian,
@aardrian@toot.cafe avatar

@mayank Oh, and Android version.

aardrian,
@aardrian@toot.cafe avatar

@mayank Thank you!

aardrian,
@aardrian@toot.cafe avatar

As expected, the Chromium intake person was unable to reproduce the issue (it may have been kit this time?), so I got 5 people to confirm and added a video:
https://issues.chromium.org/issues/342172183

I really do hate how hard it is just to get a bug to get taken up.

I mean, I had to re-file this one because the original was closed due to not reading instructions:
https://issues.chromium.org/issues/342194492

Anyway, thanks for those who helped.

juliemoynat, to accessibility French
@juliemoynat@eldritch.cafe avatar

Le mode sombre et le mythe de l'accessibilité (titre original "Dark mode & accessibility myth"), un article de @stephaniewalter où elle explique que le mode sombre pose des problèmes d'accessibilité à certaines personnes alors que tout le monde pense que le mode sombre serait mieux pour l'accessibilité…

Hé oui, ce n'est pas le cas pour tout le monde ! Elle sait de quoi elle parle, et moi aussi, parce que lire sur fond sombre est terrible pour nous.

La solution : laisser le choix entre mode clair ou mode sombre !

À noter qu'il est beaucoup plus facile pour les utilisateurices de changer un site qui ne laisse pas le choix en le passant du mode clair vers le mode sombre que l'inverse car les extensions pour passer au mode clair n'existent pas.

Donc si seul le mode sombre existe sur votre site web et que le mode lecture de Firefox n'est pas activable (il est activable sur les articles uniquement et des fois, sur certains articles, ça ne fonctionne même pas), je ferme votre site direct.

(PS : ne venez pas m'expliquer que vous avez besoin du mode sombre à tout prix. Il n'est pas dit ici qu'il ne faut pas avoir de mode sombre.)

https://stephaniewalter.design/blog/dark-mode-accessibility-myth-debunked/

aardrian,
@aardrian@toot.cafe avatar

@juliemoynat @stephaniewalter I love that the French name reads to this American as “somber theme,” like it’s sad and maybe meant for mournful piano music.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • GTA5RPClips
  • DreamBathrooms
  • everett
  • magazineikmin
  • Durango
  • InstantRegret
  • Youngstown
  • mdbf
  • slotface
  • rosin
  • thenastyranch
  • kavyap
  • ethstaker
  • JUstTest
  • tacticalgear
  • modclub
  • osvaldo12
  • cubers
  • khanakhh
  • ngwrru68w68
  • cisconetworking
  • normalnudes
  • tester
  • provamag3
  • Leos
  • anitta
  • lostlight
  • All magazines
    •