Gitter Channel Archive 21st of July 2015
What fresh hell is THIS now? - Patrick Lauke
[Karl Groves, a11y] Given the following:
<a href=“#”>foo</a> this link either a) does (supposedly) nothing at all or b) relies 100% on JavaScript to function.
That pattern begs the question: Why? Now, if this is intended to behave like a button then why not use a button? Or, at the very least, why not have a role of button?
Same thing goes for any other possible usages with JS. If it is a menu item, tab panel, custom checkbox, etc. then it should have the appropriate role applied.
[Karl Groves, a11y] The response from @dylanb wholly ignores the remainder of RFC1630 which says
The hash ("#", ASCII 23 hex) character is reserved as a delimiter to separate the URI of an object from a fragment identifier .
Later the RFC says (which @dylanb cites)
A void fragment-id with or without the hash sign means that the URL refers to the whole object.
And later says
There is no implication that a fragment identifier refers to anything which can be extracted as an object in its own right. It may, for example, refer to an indivisible point within an object.
In other words, using this pattern provides for no guarantee that the hypertext reference points to anything. In practice it might actually point to the entire window (or body). This has, historically at least, been a significant problem for users unless focus is properly managed (which it often isn’t).
I don’t have recent enough data to speak on what most modern browsers do.
spans way off the page with aria-live=“polite” and role=“alert” and sticks the new messages in them
log and getting it to announce additions. The problem is, my app is in react (redux) and it juggles the DOM nodes around constantly, so “additions” doesn’t have much meaning
[Karl Groves, a11y] > @Karl Groves, as mentioned to you previously, it would be useful for Tenon to have a feature that allows filtering/suppression of issues
@Steve Faulkner: Consumers of the API are encouraged to leverage the many API request parameters so that test results suit their needs. Additionally, if there are specific testIDs that consumers disagree with, I’d rather hear about it so we can determine if modifications are necessary. (See http://tenon.io/documentation/understanding-issue-reports.php heading starting “What do I do if…”
Also, consumers can choose to filter at runtime. In fact, Ed Gauci’s Grunt & Gulp plugins do exactly this. He offers options for which tests to ignore.
[Karl Groves, a11y] @Katy Moe: I love Firebase! One important caution: I’ve found that > 1 live region is a pain in the ass. @dylanb and/ or @Dirk Ginader might be able to comment more fully because I recall a similar conversation, but basically if > 1 live regions have the same assertiveness the announcements aren’t very reliable, esp. in VoiceOver.
My preferred workaround is to use a “notifier”, which is a single hidden live region where all announcements are made from.
[Karl Groves, a11y] FWIW I’ve written a jQuery live regions plugin: https://github.com/karlgroves/jquery-live-regions
Working in a Vanilla JS version one of these days
aria-relevant=“additions” behaviour
!important to all of its styles (no I’m not kidding :wink: ) https://github.com/Khan/tota11y/blob/c3a58c0874422e2e56fa0fa7a104f1d51fc57ff4/webpack.config.js#L7-14
disabled on fieldset and native inputs has magical powers….in the Angular world of custom controls I had to explain over and over and over that disabled didn’t actually disable anything. One place where ng-disabled and ngAria helped quite a bit, as it would spit out aria-disabled as well. Sometimes a tad verbose, but low-risk at least.
[Marcy Sutton, a11y] Everyone wants to use disabled and have it inherit like the native version. Here’s an example:
<fieldset disabled>
<md-switch></md-switch>
</fieldset>Obviously, using disabled on a custom element’s ancestor won’t disable it. Yet, people expect it will. We tell them to use ng-disabled in Angular Material because we’re packaging it with ngAria, which will add aria-disabled. But we have to jump through hoops to make sure custom controls inherit as well. It also relies on JS to do a lot. It’s a mess.
tabindex on it, that might be a good hook. I’ll have to think this through some more…I just recognize it as a pain point that I didn’t address before moving away from full-time JS framework development
disabled for everything instead of disabled and aria-disabled
disabled does in practice tbh
inert and forgetting where the boundaries are
aria-hidden on a child node, but I don’t even think that would be possible. You’d have to somehow keep a clear line up the DOM tree.
inert?
disabled is a beast.
disabled doesn't generally inherit - only for <fieldset>?
<form>?
<input type="button"/> and image and submit?
disabled?
readonly?