a11yMel,
@a11yMel@front-end.social avatar

I always want to start conversations about WCAG/guidance changes that I would like to see in the A11y Slack, but I feel like most folks want to talk about compliance instead.

For example: I want a link element to respond to the same keyboard keys as a button element does.

Another example: I think if you have alt="" and role="none" it is an acceptable demonstration of author intent and should not fail validators.

a11yMel,
@a11yMel@front-end.social avatar

Another topic and probably controversial: I wish browsers would stop trying to low-key fix author issues behind the scenes. It gives authors the incorrect impression that the code they wrote was valid when it absolutely was not. It hurts everyone in the long run.

patrick_h_lauke,
@patrick_h_lauke@mastodon.social avatar

@a11yMel true, but it hurts users more immediately in the short term

a11yMel,
@a11yMel@front-end.social avatar

@patrick_h_lauke and I agree with priority of constituents but idk, this pretzel twisting we do is how we’ve locked ourselves into never being able to really agree on things or move it forward.

“Ok so we all agree that this thing is good for a11y?”
“Wait what if developers do this one weird thing?”
“Fml who wants to work this out”

The problem stays a problem for too long because we are unable? unwilling? to call it what it is— an author error.

patrick_h_lauke,
@patrick_h_lauke@mastodon.social avatar

@a11yMel sure, but as browser developers...

"ok, so from tomorrow, we all stop correcting this particular thing silently, and show broken webpages to our users?"
"do we all have to do it?"
"yes, otherwise people will stop using our product and use yours instead because to them 'it makes the webpage work while browser X shows it all broken/wrong"

not an easy sell...

patrick_h_lauke,
@patrick_h_lauke@mastodon.social avatar

@a11yMel thinking back to the "once we use xhtml 1.1, we'll process it as actual XML, so any validation error should just show an error message and nothing else" days and how that bombed rather quickly...

kizu,
@kizu@front-end.social avatar

@patrick_h_lauke @a11yMel I think the important part is “low-key” — I love the forgiving parts of HTML & CSS, but browser (and any other) dev tools must be more harsh towards any mistakes and expose them to developers, rather than silently eat up anything invalid.

If developers are ok with typescript shouting at them even though the underlying JS works, they will be ok with HTML & CSS shouting at them too when they do something wrong.

siblingpastry,
@siblingpastry@mastodon.world avatar

@kizu @patrick_h_lauke @a11yMel I dunno ... silently fixing invalid HTML is kinda critical to how HTML5 works. Whether that was a good idea remains debatable, but that ship has sailed, I don't think we can go back without causing more problems than we solve.

kizu,
@kizu@front-end.social avatar

@siblingpastry @patrick_h_lauke @a11yMel I agree that for the user it can continue to be silent, but it should not be silent for the author.

siblingpastry,
@siblingpastry@mastodon.world avatar

@kizu @patrick_h_lauke @a11yMel Then how would the difference be reported or manifested?

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