# Pastebin QLf41qKC
03:48 <marcysutton> Trying to think of use cases where focus should be sent to an interactive element such as a button or link upon a context change. Typically we send it to a heading or wrapping `<div>` with `tabindex="-1"`, depending on content. Any interface designs where you\'92ve sent it to a link or button instead? Usually a heading is the first thing that makes sense to programmatically send focus, no? I\'92m talking primarily about view changes in client-rendered apps like Angular, Ember or React.\
03:49 <Michiel> An action dialog with OK and Cancel button maybe?\
03:50 <Michiel> Fromt he APG: \'93When a modal dialog opens focus goes to the first focusable item in the dialog. Determining the first focusable item must take into account elements which receive focus by default (form fields and links) as well as items which may have a tabindex attribute with a positive value.\'94\
03:50 <Michiel> http://w3c.github.io/aria-practices/#dialog_modal\
03:51 <Michiel> It is a context change, but maybe not the one you're looking for.\
03:51 \'97 Michiel does Obi-Wan style gesture\
09:19 <marcysutton> But wouldn\'92t there be a heading before the OK or Cancel button that would communicate more about the experience in the correct order?\
09:23 <marcysutton> I\'92m writing about focus management and just wanting to make the best recommendations. \'93It depends\'94 is so hard to communicate.\
09:23 <marcysutton> Focusing on headings with `tabindex="-1"` seems so nice because you can direct a user to new content and they can TAB to the nearest interactive element.\
13:04 
\f1 \uc0\u8594 
\f0  walbo joined (walbo@irc.tinyspeck.com)\
14:56 <Michiel> marcysutton: which users would benefit from that?\
14:57 <Michiel> I've made a implementation of the APG dialog here: https://dir.rawr.eu/research/dialog/index.html\
14:57 <Michiel> VoiceOver reads that out correctly.\
14:57 <Michiel> I don't have access to NVDA or JAWS at the moment.\
15:03 <Michiel> Of course, VoiceOver on iOS messes it up.\
15:03 \'97 Michiel grumbles about Apple being inconsistent again\'85\
15:15 <Michiel> https://twitter.com/MichielBijl/status/726398637736116224\
16:35 <Michiel> Have updated with JAWS, Narrator, and Orca results: https://dir.rawr.eu/research/dialog/index.html\
16:39 <hmig> @marcysutton: I\'92ve set the focus to a button if that is the next logical step for the user.  User selects product, code sets focus to the \'93next\'94 button. The user can still tab around, but by setting the focus they don\'92t have to tab in order to continue with the purchase.\
16:41 <Michiel> :+1:\
18:46 <marcysutton> If you're a screen reader user, does sending focus straight to a button mean you have to navigate back up in the source order to gain context?\
18:47 <marcysutton> I'm writing focus management recommendations and the hardest part is saying "it depends"\
18:51 <Michiel> Well, it depends.\
18:52 <Michiel> 
\f2 \uc0\u55357 \u56833 
\f0 \
18:52 <Michiel> If you have a look at my research page; you'll see that the title and dialog message are read by AT.\
18:52 <Michiel> So you wouldn't have to move back up.\
18:53 <Michiel> This is just dialogs though.\
18:53 <Michiel> If it's an entire page, it would default to the top of the page/document.\
18:59 <marcysutton> Also I may have mixed work and whiskey last night :stuck_out_tongue_winking_eye:\
19:02 <Michiel> I do that every night, no other way to work.\
19:02 <Michiel> How do you think we came up with http://roledrinks.nl? :P\
Sunday, May 1st, 2016\
01:43 <marcysutton> :beers:\
Tuesday, May 3rd, 2016\
20:15 <marcysutton> @michiel: I do like that your example includes a \'93butt-dialog"\
20:17 <marcysutton> Considering the guidelines I\'92m writing are for page changes in a SPA and not a dialog though, I think I\'92m going to stick with my original recommendation: send focus to a wrapping element (with limited content) using `tabindex="-1"` so that keyboard and screen reader users are directed to the right context. Hitting TAB will go to the next interactive item\
20:17 <marcysutton> Alternatively, send focus programmatically to a heading with `tabindex="-1"` on it if the wrapping element contains an unreasonable amount of content to read aloud\
23:36 
\f1 \uc0\u8594 
\f0  paintingemily joined (paintingemily@irc.tinyspeck.com)\
Wednesday, May 4th, 2016\
05:27 Connection closed unexpectedly\
05:27 
\f1 \uc0\u8594 
\f0  Michiel joined  \'95  Channel mode: +nt  \
Thursday, May 5th, 2016\
23:09 <robdodson> @marcysutton: that's what I've been doing (focusing headings on text heavy pages)\
23:10 <robdodson> something I've been wondering... for complex controls there seem to be two ways to kind of manage focus (or focus-like behavior). Roving focus and aria-activedescendant. I'm trying to decide when to use roving focus vs activedescendant. Any advice?\
23:13 <Michiel> @marcysutton: re focus on view change. I'd consider a view change a page change. So reset to start of document, not a heading within it.\
23:14 <Michiel> Would be an interesting thing to user test of course.\
23:15 <Michiel> And yeah, I was going to implement two different dialogs, so needed to differentiate the ID's. Left it in when I decided not to do the second one :P\
23:15 <marcysutton> so then the -1 on a wrapping DIV would be the way to go. In the app I am talking about it opens panels on top of the existing page (and disables every link behind it), so focus management is really important.\
23:19 <robdodson> @michiel: I think resetting it to the document could be annoying as you may need to tab through the navigation again (if there's no way to skip to the main content)\
23:20 <Michiel> Then it fails 2.4.1 and skip links should be added ;)\
23:20 <Michiel> marcysutton: okay, I don't have enough experience with such applications to make much sense of that.\
23:21 <marcysutton> it has skip links.\
23:21 <robdodson> here's an example that does what I think marcy is getting at http://robdodson.github.io/udacity-a11y/lesson2-focus/08-spa-example-solution/#!/what-is-vegemite \
23:21 <robdodson> not quite the same thing (it's not opening new panels) but it's a simple single page app that focuses headings\
23:21 <Michiel> Surely those are just pages?\
23:22 <Michiel> So should reset to top of document.\
23:22 <marcysutton> Why? Then the user would have to tab through to get to the new content.\
23:22 <marcysutton> Tabbing through things they have already tabbed through to get there.\
23:23 <robdodson> and wait for the screenreader to announce all the navigation again i'm assuming\
23:23 <Michiel> Which is the same as on any other webpage is it not?\
23:23 <marcysutton> In the app I\'92m working on, when a new panel is opened focus is sent into it, escape closes it. It is not the same as a plain HTML page.\
23:24 <Michiel> That sounds like a dialog to me.\
23:24 <marcysutton> It isn\'92t :)\
23:24 <marcysutton> not everything is a dialog!\
23:24 <Michiel> :P\
23:24 <Michiel> Well, if you can close it with esc.\
23:25 <Michiel> In any case, I'm not saying setting focus to the heading is an awful thing; but it is not consistent with \'93old fashioned\'94 webpages.\
23:25 <Michiel> You wouldn't set focus to a page's h1 when it loads.\
23:26 <Michiel> I would argue that it is confusing to the user.\
23:26 <Michiel> Suddenly, the navigation isn't in the tab order anymore.\
23:26 <Michiel> Not going forward anyway.\
23:27 <Michiel> Which might be less of an issue of there are landmarks etc.\
23:27 <Michiel> Still, it doesn't match user expectation as far as I can tell.\
23:28 <Michiel> And it might be different for something like the panels you speak of, but I don't know what those are.\
23:28 <Michiel> What Rob linked to are pages to me, so they should set focus to the start of the document.\
23:28 <Michiel> It's either pages or tabs, but they're not marked up or designed as such.\
23:29 <robdodson> yeah i think of them as pages, it's meant to be a single page web app example\
23:30 <Michiel> Well, I don't know which SC is relevant right now.\
23:30 <robdodson> hm I guess i was thinking it would be a burden to reset focus to the document but now I'm curious to put this example in front of some real AT users to hear what they think\
23:30 <Michiel> http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html maybe\
23:31 <Michiel> I think it applies more to keyboarders.\
23:31 <Michiel> AT users might use things like Web Rotor etc.\
23:35 <alice> There does often seem to be some tension between what works well for non-AT kb users and what works well for AT users\
23:35 <alice> cf. the recent tabpanel brouhaha\
23:36 <alice> well actually, s/AT/screen reader/\
23:36 \'97 Michiel still has nightmares about tab panels.\
23:36 <alice> I think I do specifically mean screen readers here\
23:36 <alice> I think @robdodson has had those same nightmares\
23:38 <marcysutton> There is a point to consider: a legit web application is NOT an old fashioned webpage.\
23:39 <alice> @marcysutton: Right on\
23:39 <marcysutton> To make it intuitive and usable there are some things to think about, like what is the best place to set focus? In the case of this giant app I\'92m working on, resetting it back to the top would be a pretty terrible experience for a keyboard and screen reader user alike.\
23:40 <Michiel> I agree. And in this case you can judge that way better than I ever could :)\
23:41 <Michiel> In case of a website (those things with mostly text), I would set it to the top however.\
23:51 <robdodson> since there are so many smarties here I want to try my previous question again: Roving tabindex or aria-activedescendant. Trying to decide when one pattern is more appropriate than the other. Any thoughts?\
23:55 <cordelia> I have found VO\'92s support of aria-activedescendant to be a little buggy lately :disappointed:\
23:57 <Michiel> robdodson: tabindex for better support.\
23:57 <robdodson> good to know, thank you both!\
Friday, May 6th, 2016\
04:05 <feather> YMMV, This is all IMHO, etc disclaimers, yada yada yada. \
04:05 <feather> If you think of a SPA as one really big, long, flattened page, links that launch new "views" are effectively the same as sending the focus to a named anchor (old school) or fragment identifier (new school). Those newly visible chunks of content could easily have been already there in the page. The link points to #editview which represents a chunk of he page -- the part that holds the view you just displayed. It gets announced as an internal link. - people expect to go to another part of he page. And that's what we do. Setting focus to the heading takes the person there, hopefully reading the heading (depends on the screen reader). Setting focus to the heading works, generally speaking and always has. The roots of many modern techniques are based in tried and true HTML mechanisms for doing things. \
04:05 <feather> We've got an Angular 1.0 example for people to play with - linked from our article: sateach.es/spangular  \
04:05 <feather> Focus on the headings is deliberately visible so people can see what's going on. We'd never put something like that into production. It has worked reasonably well. Full user testing coming up soonish with one of our clients soon with a single page app using these techniques - we will likely write about it :)\
04:47 <robdodson> @feather: thanks for sharing the post! Something I'm wondering... you mention how the links are announced as "internal link" because they're using hashes. In a SPA where I'm using pretty URLs I may be linking to a page without the hash, so `/editview` for instance. In that case if I recall correctly it would just announce as "link". I wonder if that makes a significant difference in how folks would perceive it}