[lozandier]@stevef Howdy & belated New Year; If memory serves me right you highlighted a proposal for uh for HTML 5.2; is there any update on that you may be aware of? I had a hard time searching for updates with perhaps naive queries on Google
[lozandier]@marcysutton :waves: As you know, a huge fan of Axe; when it comes to Axe & its color contrast auditing capabilities, have you had a moment to digest the CSS Color Level 4 specification—particularly the current capabilities contrast() is expected to have?
@powrsurg having a focusable inside a focusable is weird. It seems to work ok in Firefox with Orca but have heard there are issue with other browser/AT combos
It's like having a div with role=button and all the buttony stuff and then having an anchor inside that div... except, this hasn't been resolved fully with summary/details (the whole thing opens but what if the details has a link inside or something? etc)
At this time I'm just going to implement a standard button with the expansion dealie that I had before. Still, I do have a hard time judging when that is appropriate vs when details/summary would be more appropriate. And all of this following a textarea where the expanded text is a helper description I'm not sure how it should apply. I almost went with making the expanded text an aria-describedby for the textarea
I feel like details/summary should be the most appropriate for all, except it's not working in much yet so using what works makes more sense at this time.
Or... maybe simply a mention of the other control in the textarea's label would work? Or is that too much blah-blah for that label
I think details/summary should be great when everything's pure text. There are still some issues though with things like, what if the visible part is a heading? Someone (VO?) has a bug where that role gets lost
Now that I think of it, I should have encountered similar problems when I had sections who were javascript focusable with tabindex=-1 (for in-page skip links with javascript smoothscroll for all those browsers who #fail at in-page focus) when those sections had focusables inside.
It's a lot of text. The textarea is where clients can modify the custom registration email that anyone signing up for their account. The button with text after reveals things like custom variables for the account username/email, our recommended support numbers/address, and how they can reset the message back to default.
@mfairchild365 nice article. It felt kinda weird to see "sr-only" on the skip link. SR users having the ability to nav by region already while I would benefit from the skip link... but I wonder if "sr-only" is starting to become a sort of standard name for visibly-hidden anythings...
Powrsurg I wonder if it's good enough then, when the user's at the textarea, to add a quick few words saying "some advanced options available below" or something
so people go into that textarea knowing there's more
[melsumner] Question: we have been having some discussion in the office about whether or not it is okay to have a different experience for a user who is fully-sighted - in this case, a complex business UI where visual cues give support to "power users"
[melsumner] Any user can still complete their workflow, but I am feeling a little bit like, I can absorb so much more visually than I could in perhaps an auditory way( I'd want instructions to be explicit and simple if I only had to listen) and to that end I'm not all that opposed to the idea
[melsumner] But then I feel like we're ignoring users who have cognitive differences
[melsumner] Should I separate it out into an option, like a preference?
I think that ties into the idea that, visually, we can receive info a bit async, while audial we feel we're stuck with sequential info
If it's an interface the users return to regularly, you'd think anyone interested in being a power user may want that option even if they can't take advantage of the visual hints.
But maybe a preference option is a good compromise...
@StommePoes doh'! Thats some good feedback re the "sr-only" skip nav. I will take a closer look at that. I believe that came from the bootstrap skipnav example. Do you think it is actively having a negative impact on a11y, or is just a little odd because sr-only users probably wouldn't need to use it?
[melsumner] You know, a cool thing we are doing with Ember (& single page apps) is auto-skipping all of the header stuff that (is the same) and sending focus directly on the relevant content for that workflow.
[dylanb]@lozandier we have to wait for implementations so we can play around with what it really means
[dylanb] it references the “base color” and does not really talk about transparency, so while I expect it will make it easier to make colors with high contrast, I think in reality it will have minimal impact on either the algorithm we use or the reality of color contrast in the wild
@mfairchild365 "Do you think it is actively having a negative impact on a11y, or is just a little odd because sr-only users probably wouldn't need to use it?" nah, it's just a class name. I can see it on focus, so it works fine for me as sighted keyboarder, no AT, which is who it needs to work for.