A11y Slacker archive 2015-10-26

MichielBijl

10:33

@jitendra interesting, definitely trying that one out!
MichielBijl

10:33

@Joe Watkins @LjWatson is one to follow on Twitter :)
MichielBijl

10:34

joe-watkins/top-people-to-follow-in-web-accessibility#1
zakim-robot

11:22

[jitendra, a11y] Which captacha system is accessible?
powrsurg

13:22

Okay, it looks like @stevefaulkner and others replied after I left on Friday ... So it seems like Oaap is not a good site for looking up accurate examples of how you should do things. Aria-expanded should only be used on controls. And aria-hidden is only needed when you're doing something like setting the height to 0 to hide things, rather than display: none;
powrsurg

13:22

Is that correct?
powrsurg

13:24

This looks like I need to go back and fix a bunch of code. I based my understanding of aria-expanded on the page I linked to earlier, which was wrong :(
MichielBijl

13:24

@powrsurg display: none; has the same effect as aria-hidden
MichielBijl

13:24

I like to use aria-hidden as a trigger for display: none;
powrsurg

13:25

Well, in browser that support aria stuff
MichielBijl

13:25

e.g. [role=dialog][aria-hidden=true] { display: none }
powrsurg

13:25

We have clients that still need IE8 support
powrsurg

13:26

oh well, I guess that works too
MichielBijl

13:26

Allows you to skip arbitrary classes like .modal-hidden
MichielBijl

13:26

That selector should work even in IE8
powrsurg

13:26

I thought one should use aria-hidden also on things that you wouldn't want spoken, but want to show visibly
powrsurg

13:27

yeah, I haven't had enough coffee yet. I see that
MichielBijl

13:27

@powrsurg that too. I never quite get why you'd want to show something but not have it spoken.
powrsurg

13:28

sadly, I find it useful when trying to clean up work others did where they would do stuff like add a "|" in as text rather than as CSS to delimit stuff
MichielBijl

13:29

Sounds plausible :)
MichielBijl

13:29

I'd rather fix it through css (if possible)
powrsurg

13:30

I mean, look at the header on JAWS home page. They're using it on the "|"s

MichielBijl

13:30

li + li::before {   display: inline-block;   margin-left: 0.4em;   padding-left: 0.4em;   border-left: 1px solid #333;   content: ''; }

MichielBijl

13:31

Or something like that. And off course I forgot ::before. Only use :before in IE8.
MichielBijl

13:31

Easier than adding [aria-hidden] to all the things me thinks.
powrsurg

13:34

Yeah, that makes too much sense ...
powrsurg

13:43

So if Oaap is not a good site for examples, what is?
MichielBijl

13:44

The Paciello Group blog
MichielBijl

13:44

Or the HTML spec
MichielBijl

13:44

Or the Authoring Practices Guide (not much examples as of yet)
powrsurg

13:47

Yeah, I follow the Paciello blog. Just doesn't have things in as nice a format as Oaa did as it was quick to look up stuff directly
MichielBijl

13:48

The APG works on new examples, but lack developers.
MichielBijl

13:48

We are three strong; not nearly enough.
MichielBijl

13:49

@heydon has some nice examples on his website
MichielBijl

13:49

http://heydonworks.com/practical_aria_examples/
powrsurg

13:51

I've used heydon's stuff a bit
powrsurg

13:51

In his examples of tabs, shouldn't the links with role tab have aria-expanded on them?
MichielBijl

13:53

It has aria-selected, so that should suffice.
powrsurg

13:53

so ... when do you use aria-selected?
MichielBijl

13:54

Excuse me
MichielBijl

13:54

“For a single-selectable tablist, authors should hide other tabpanel elements from the user until the user selects the tab associated with that tabpanel. For a multi-selectable tablist, authors should ensure each visible tabpanel has its aria-expanded attribute set to true, and that the remaining hidden tabpanel elements have their aria-expanded attributes set to false.”
MichielBijl

13:55

http://w3c.github.io/aria/aria/aria.html#tab
MichielBijl

13:55

Heydon's example is a single-selectable tablist AFAIK
MichielBijl

13:55

Depends on how you interpret selectable.
MichielBijl

13:56

Is it a list with one tab, or a list where only one tab can be active?
powrsurg

14:03

I'd say the latter
MichielBijl

14:05

Then aria-expanded is not needed per spec.
zakim-robot

14:07

[dylanb, a11y] accordion example http://oaa-accessibility.org/example/35/
powrsurg

14:08

@dylanb I don't know how to feel about oaa since the examples I've referred to gave me the wrong impression of when to use aria-expanded in the first place
powrsurg

14:13

http://oaa-accessibility.org/example/20/ is what got me specifically
zakim-robot

14:14

[dylanb, a11y] @powrsurg use aXe to check markup for ARIA compliance
powrsurg

14:14

said page doesn't show any errors in aXe ...
zakim-robot

14:15

[dylanb, a11y] there also happens to be nothing wrong with it
zakim-robot

14:16

[dylanb, a11y] at least as far as the standard is concerned
zakim-robot

14:16

[dylanb, a11y] if it doesn't work, then that is a problem with the implementations and should be reported as a bug
powrsurg

14:17

Shouldn't the aria-expanded be on the controls, not the element then?
zakim-robot

14:17

[dylanb, a11y] are you talking about the region?
zakim-robot

14:17

[dylanb, a11y] http://www.w3.org/TR/wai-aria/roles#region
zakim-robot

14:18

[dylanb, a11y] it is absolutely allowed to have an expanded attribute
zakim-robot

14:18

[dylanb, a11y] and the aria-controls indicates the relationship
powrsurg

14:19

See this is what I mean, is expanded used to control something, or to indicate the current state of that given element?
zakim-robot

14:19

[dylanb, a11y] yes
zakim-robot

14:20

[dylanb, a11y] sorry, humour does not work online - both
powrsurg

14:20

heh
zakim-robot

14:20

[dylanb, a11y] the button does not expand
zakim-robot

14:21

[dylanb, a11y] what the button controls, expands
zakim-robot

14:23

[dylanb, a11y] but I believe this is widget-dependent and confusing
zakim-robot

14:23

[dylanb, a11y] you need to read the specs closely to see where what goes
zakim-robot

14:23

[dylanb, a11y] it is not obvious
powrsurg

14:23

But in the example 35 you linked to the expand is on the button, not the tabpanel
zakim-robot

14:24

[dylanb, a11y] exactly
zakim-robot

14:24

[dylanb, a11y] see what I mean
powrsurg

14:24

That's the opposite of example 20 though
zakim-robot

14:25

[dylanb, a11y] and that is becase they are different widgets
zakim-robot

14:25

[dylanb, a11y] roles
zakim-robot

14:27

[dylanb, a11y] wait until you try to implement menu :simple_smile:
powrsurg

14:28

... Okay, that is ... convoluted. Luckily it sounds like where I've (and we're I've got my co-workers to use it recently) been using it have been right then
powrsurg

14:29

Still, the attributes having different meaning and behavior for different widgets seems unnecessarily complex ...
zakim-robot

14:29

[dylanb, a11y] yes, it is not logically consistent
zakim-robot

14:31

[dylanb, a11y] anyway, that is why I suggest using aXe, because it will tell you when something does not conform to the spec
zakim-robot

14:31

[dylanb, a11y] which is a useful piece of information to have when trying to figure out why something is not working
powrsurg

14:33

Yes it is. I've had nothing wrong in aXe but I know that some things still require manual testing hence I thought this might be one of those things
powrsurg

14:34

I was working on our first tabbed interface and making that work and saw the examples and it was going against what we've been doing and I thought the attributes would be logically consistent and that got me questioning everything
zakim-robot

14:34

[dylanb, a11y] https://changingnewsroom.files.wordpress.com/2014/06/question-all-the-things.jpg
zakim-robot

14:35

[dylanb, a11y] alt: Question all the things
powrsurg

14:36

Incidentally, is there a way to get aXe to appear on a Firebug tab?
powrsurg

14:37

... and I just crashed Firefox having axe up on the wrong tab and trying to switch tabs to get it on the right one ...
zakim-robot

14:37

[dylanb, a11y] no, but in the FF dev tools
zakim-robot

14:37

[dylanb, a11y] Firebug's days are numbered
zakim-robot

14:37

[dylanb, a11y] and the number is not high
powrsurg

14:39

Yeah, with the death of XUL I suspect that will be the case
powrsurg

14:39

I've been a Firebug user since forever =/
zakim-robot

14:39

[dylanb, a11y] and all the other APIS that it uses that are all going away
zakim-robot

14:40

[dylanb, a11y] WAVE and FireEyes are also suffering from the Firefox changes
powrsurg

14:41

I honestly don't get what Firefox is doing, but that's a rant for another room :p
garcialo

14:51

well WAVE has been suffering on FF for a bit
garcialo

14:51

is there something else from the newer changes?
stevefaulkner

15:18

@powrsurg

So it seems like Oaap is not a good site for looking up accurate examples of how you should do things.

Not in the case of aria-expanded at least.

Aria-expanded should only be used on controls. And aria-hidden is only needed when you're doing something like setting the height to 0 to hide things, rather than display: none;

In practical terms if you want to hide something from everyone display:none and friends is enough. If you want to hide stuff just from screen reader users then aria-hidden=true is enough as long as the hidden content does not include interactive elements.
zakim-robot

15:21

[Claire Ryberg, a11y] I'm being asked by a designer to implement two buttons, one that is visible and keyboard tab-able but hidden to a screen reader that reveals a non-accessible version of Content A, and another button that is hidden visually but is tab-able and accessible by screen reader only and reveals the same Content A, but in an accessible format.

Is creating content that is tab-able by screen reader only even possible, let alone advisable? I'm getting all sorts of red flags with this request.
garcialo

15:25

that's an interesting alternative to having an entire additional "accessible site"
powrsurg

15:25

@stevefaulkner so @dylanb is incorrect about it being inconsistent and that it's different based on the widget?
stevefaulkner

15:27

which being inconsistent?
stevefaulkner

15:28

@powrsurg ^^
zakim-robot

15:28

[Claire Ryberg, a11y] @garcialo: it's their answer to trying to make an existing web application accessible. A lot of it has already been refactored to be accessible, but the way this one page was originally designed doesn't seem refactorable without a complete redesign and reimplementation. I think the idea is that having an accessible version will be "more simple" than a complete redesign
StommePoes

15:28

Claire: sounds like building a sinkhole, would do anything possible to avoid. Ask the designer to explain two colleagues working on this page, one completely blind and one sighted. How do they coordinate? (usually a good question to ask when someone suggests an "accessible" and an "inaccessible" version of something.
powrsurg

15:29

@stevefaulkner in http://oaa-accessibility.org/example/20/ expanded is used on the controls (like you're saying) while in http://oaa-accessibility.org/example/35/ it is not used on the tab (the controls), but rather on the tabpanel.
powrsurg

15:29

er
powrsurg

15:29

no
powrsurg

15:29

I said that backwards
powrsurg

15:29

in 20 it is used on the region while on 35 it's on the controls
zakim-robot

15:30

[Claire Ryberg, a11y] @StommePoes that's a good way to think about it, thank you. We do tend to talk about sighted and non-sighted users as if they never interact with each other, and that's just not realistic.
zakim-robot

15:32

[Claire Ryberg, a11y] Out of curiosity though, is there a way to make something tab-able by screen reader only? At present, I don't know of any way to signal to the javascript of a page that a screen reader is being used.
stevefaulkner

15:34

@powrsurg suggest best place to it is where it most likely to be encountered and understood by user, which is on a control that controls display of another element
powrsurg

16:13

Right, but that goes against what the examples there suggest. And aXe is not reporting any errors either ....
MichielBijl

16:41

@Claire Ryberg: screen reader users don't tab, they use modifier keys :)
MichielBijl

16:42

There are bound to be users that tab though
MichielBijl

16:42

It's not black/white
MichielBijl

16:47

Screen reader users aren't necessarily blind either.
zakim-robot

16:48

[Claire Ryberg, a11y] Yeah, that was going to be my first response to the designer.
zakim-robot

16:48

[Claire Ryberg, a11y] The whole thing just strikes me as a bad idea....
MichielBijl

16:50

If there is an accessible version, why not just show that?
MichielBijl

16:50

Why even have the inaccessible version around?
zakim-robot

16:54

[Claire Ryberg, a11y] Their argument, not mine: The inaccessible version has the desired workflow, with drag and drop and resize, etc. That all just gets read as a list to an unsighted user, so we should just display it as a list to them! They can rearrange using up and down arrow keys.
MichielBijl

16:55

Okay
zakim-robot

16:55

[Claire Ryberg, a11y] How does the same order get translated from a drag and drop grid to a single column list? Eh.......
MichielBijl

16:55

So is the drag and drop thing a grid or something?
zakim-robot

16:56

[Claire Ryberg, a11y] It's displayed as a grid, but the html is ul, li
MichielBijl

16:56

Okay, so the difference is in the CSS?
MichielBijl

16:56

Or the styling rather
zakim-robot

16:56

[Claire Ryberg, a11y] Yeah, and then the keys to interact with it
MichielBijl

16:57

Sounds like the grid thing is unnecessary.
MichielBijl

16:57

If the same effect can be achieved with a simple list…
MichielBijl

16:57

So the design doesn't comply with the functionality.
MichielBijl

16:57

But please correct me if I'm wrong.
MichielBijl

16:59

But, since this isn't helping, let's try to solve this and get better arguments
MichielBijl

16:59

I'd simply start with asking them why the accessible version isn't the only version.
MichielBijl

16:59

Or why it is necessary to display the list as a grid.
MichielBijl

17:00

Or even why they felt a grid would be more practical than the list it is markedup to be.
MichielBijl

17:01

They obviously felt the need to design it like they did, the question is simply why?
zakim-robot

17:07

[Claire Ryberg, a11y] I wouldn't say the grid is unnecessary, I think the real issue is that we're trying to retroactively add accessibility to a design that's already been implemented, without making any changes to the design.
Without going into too much detail, the grid of li's represents a page the user is building for themselves, where every grid item represents a table of data (this screen shows no actual data, just where it would go on the built page). A sighted user can drag/drop/resize the grid boxes to determine the data that they want to see on this built screen. It's supposed to have a sort of "wow" effect for the client, and they really want it.
But none of that "wow" effect conveys to a non-sighted user, so I think the idea is to try to direct those users to an accessible screen instead that would be more straight forward to manipulate
zakim-robot

17:08

[Claire Ryberg, a11y] but that doesn't solve the issue for sighted users who prefer to use a screen reader or keyboard, so I think the real answer I'm hearing is that I need to push back on this "accessible version" idea
MichielBijl

17:15

How then does the accessible version handle columns and what not?
MichielBijl

17:15

How do you do layout if you can only position elements vertically?
zakim-robot

17:17

[Claire Ryberg, a11y] I've been told they have a solution for that, but not what it is.
zakim-robot

17:17

[Claire Ryberg, a11y] So, like I said before.....lots of red flags....
MichielBijl

17:19

Yeah there are to many questions to go forward if you ask me.
zakim-robot

17:21

[Claire Ryberg, a11y] I've gotten a lot of good points I can bring up to them from this conversation, thank you for the input!
MichielBijl

17:24

That's why we're here!
MichielBijl

17:24

Would love to here the outcome if you're allowed to share.
zakim-robot

17:28

[Claire Ryberg, a11y] I'll keep you (vaguely...) update!
stevefaulkner

17:44

@powrsurg

Right, but that goes against what the examples there suggest. And aXe is not reporting any errors either ....

its not a conformance error to use on quite a few roles http://www.w3.org/TR/wai-aria-1.1/#aria-expanded, so you wouldn't see an error, its more about what works best in real world implementation.
zakim-robot

18:57

[Joe Watkins, a11y] @stevef @michiel : tnx :simple_smile: added Léonie
zakim-robot

19:35

[dylanb, a11y] @stevef: I would like to see ARIA be slightly more prescriptive about what is announced when...there seems to be quite a few gaps between what conforms and what actually works
zakim-robot

20:49

[Joe Watkins, a11y] Posting this again in the event folks missed it over the weekend.. feel free to add to the list! https://github.com/joe-watkins/top-people-to-follow-in-web-accessibility
zakim-robot

21:29

[Jordan Scales, a11y] does aria-hidden not apply inside control labels?
MichielBijl

21:30

What do you mean Jordan?
zakim-robot

21:31

[Jordan Scales, a11y] http://jsbin.com/zefasipiso/edit?html,output “world” is read off in both of these examples when I focus the radio button
MichielBijl

21:34

Works fine in VoiceOver on Safari 9
MichielBijl

21:34

What combo do you test with?
zakim-robot

21:36

[Jordan Scales, a11y] voiceover on osx 10.10 with chrome 46
zakim-robot

21:36

[Jordan Scales, a11y] looks like safari honors the aria-hidden!
zakim-robot

21:36

[Jordan Scales, a11y] firefox and chrome are reading off its contents...
MichielBijl

21:43

VoiceOver doesn't offer support for other browsers AFAIK
MichielBijl

21:43

ChromeVox for Chrome
MichielBijl

21:44

Still, shouldn't happen
MichielBijl

21:44

If the browsers expose it correctly through the accessibility tree; VO shouldn't announce it.
zakim-robot

21:45

[Jordan Scales, a11y] I’ll fiddle with chromevox
garcialo

21:46

@stevefaulkner is always so insightful. https://medium.com/@stevefaulkner/move-over-twitter-medium-is-the-next-microblogging-platform-d1efd0a28b2b#.ds4sr9we2
stevefaulkner

21:46

@dylanb

I would like to see ARIA be slightly more prescriptive about what is announced when...there seems to be quite a few gaps between what conforms and what actually works

ARIA does not prescribe how AT express the aural UI, only how stuff is mapped to acc APIs in browsers. There is room/opportunity for mapping the aural UI of ARIA and describing expected expression of semantics vis the actual expression in AT.
stevefaulkner

21:48

@garcialo playing with the medium
stevefaulkner

21:49

@garcialo u sarky 💩
stevefaulkner

21:53

@MichielBijl

If the browsers expose it correctly through the accessibility tree; VO shouldn't announce it.

it's a not well defined aspect of acc name calculation, hidden elements still contribute to accessible names for aria-labelledby relationships, but it is not defined AFAIK whether native label-for relationships should work likewise, need to spec it...
MichielBijl

21:56

@stevefaulkner you know what to do ;)
stevefaulkner

21:59

@MichielBijl bug filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=29245
zakim-robot

22:01

[Jordan Scales, a11y] @stevefaulkner thanks!
stevefaulkner

22:01

:+1:
stevefaulkner

22:18

@jdan see comment from Alex Surkov (moz acc engineer) https://www.w3.org/Bugs/Public/show_bug.cgi?id=29245#c1
MichielBijl

22:18

@stevefaulkner thanks for the file.
stevefaulkner

22:19

np
StommePoes

23:44

random kitteh =^.^=
MichielBijl

23:44

Haha
MichielBijl

23:44

Oh you

Gitter Channel Archive 26th of October 2015