[techthomas] Did you all know New York City has new accessibility requirements? >On March 14, New York City became the first major municipality in the United States to adopt legislation mandating accessibility standards for all of its government agency websites. Serving a population of over 8 million, the New York City government includes more than 120 agencies staffed by approximately 325,000 employees.
[deborah_kaplan] and gets across the point that ARIA should be used as a last resort, not a first. Native HTML is always a better choice when it serves the purpose.
[deborah_kaplan] Most web apps aren't really true webapps; google docs and slack are the exception rather than the rule. For the most part, users expect webpages to behave like webpages.
[deborah_kaplan] I'd argue that making web pages which don't behave like the web should be primarily restricted to tools users use so often they different UI and UX can become second nature: gmail, google docs stuff, facebook tools, slack... tools that users can become expert in. Otherwise, webapps should still follow the patterns users expect in their browsers.
the problem is that the browser behaviour is really inefficient for a keyboard user. We need to do something about that. Like you I don't think we are ready (yet) for "web page" tabs to be ARIA tabs, but I hope the day will come when we are.
[deborah_kaplan] I mean, I'm also a big advocate for ARIA being something that gets exposed not to AT -- so, for example, <div role=button> wouldn't need tabindex plus javascript, because the user agent would understand that the ARIA means it should change something about the keyboard work.
we have talked about changiong browser behaviour before (I remember a F2F at Mozilla in Toronto), particularly around adding things to the keyboard focus order with certain aria roles
[deborah_kaplan] I understand about the politics of it. But I also think that, in the long run, it's more practical to convince under 50 browser manufacturers to change the way they implement ARIA, than it is to convince hundreds of thousands of web developers to learn about the correct way to make a button div, using tabindex and keypress JS, and then have millions of users have to download an extra bit of JavaScript making all of the pages bigger.
i'm actually very much against it as the default, as I've worked on a number of UIs where we deliberately exclude certain elements from the keyboard order becuase there are multiple methods of operating the same controls
[deborah_kaplan] Ultimately, I am confronted with countless page elements I can't access on websites. Many of them make it difficult for me to do my job. It's always going to be more successful to make it harder for individual web developers to fail.
[deborah_kaplan] I guess I disagree. I know it's not a fight I can fight successfully -- I'm not on WAI-ARIA ;) -- but I'm (1) a keyboard user who is unable to use a lot of the web, and (2) an accessibility person constantly trying to train developers that there are *three* different things they need to do to every role=button (and all of the other examples of places I wish the browsers parsed the ARIA).
[alice] I'm interested in the trade-offs between on the one hand, treating something like a tablist as a single tab stop which means fewer tab stops in the page to "tab through" to get to other UI; on the other, providing the more predictable "tab visits everything" behaviour
[deborah_kaplan] yeah -- @alice, I'd really like a settled behaviour. For both keyboard and screen reader users, a full sequential list of tabs is a problem--especially on mega menus. But the question of what is the most common behavior users will try is an open one. I think I would just like to have a lab with a bunch of usability tests.
[deborah_kaplan] I think I probably try arrow down, then space, then tab, then enter, then give up in frustration and close the page, in that order, but as users we tend to have inaccurate ideas of how we use computers, so I might be wrong about myself.
[deborah_kaplan] Like, if they are modeled to look like Microsoft Windows drop-downs, or with down arrows, I might expect them to behave less webby and more app-y.
I think most importantly it proves that "well that's how desktop apps work" does not mean that's how web users will expect things. I kept getting told over and over about how desktop apps work... and now I cannot find the study that showed people recognising the side-arrow for Play and the double pipe for Pause when on a video recorder/DVD player, but not recognising them on a web page.
I guess if we decide we will use the ARIA-keyboard-rules, then web devs everywhere will have to start writing little how-tos to retrain people. Which would take years, but could be done.
And I assume what I do when I get stuck on a page, isn't what "normal" (non-dev) people do, as I haven't seen people do it... I hit ctrl-l to get to the address bar since from there I can re-start into the page.
Hmm no I thought it was, but is apparently more of a sausage-in-a-croissant (genius!). Saucijzenbroodje is the less imaginative "sausage roll", according to WikiPedia.
The research data that we have at the moment tells us that both the current APG recommendation and the tab to all tabs in the tablist and activate with space/enter are seen as equally accessible/usable.
There are definite downsides to what the APG currently tells you as in that it captures your down/up-arrows. And some people use those to scroll pages.
[jhausler] ok, so the question…. what would be stranger.. having ot tab past my menu trigger to get to the tabpanel, or having ot arrow to the menu trigger?
if the tabs were normally activated by focus, then the menu could be opened with enter. Howeve rif the tabs are activated by enter then I'm not sure what one expects if enter now does something else... this is a question that has hit people trying to decide how to deal with submenus in a webby navigation menu... what should click do?
[jhausler] you can open as many tabs as you want in my interface.. it’s the users’ call. we just have to provide a way to deal with them if it gets to big for the screen.
[jhausler] so i have 1 vote for “arrow to the menu trigger”? i wouldn’t want to put role=“tab” on it though.. since it doesn’t control a panel. it would have aria-haspopup=“true” since it’s a menu trigger..
In the Perl community, there were these old nasty Perl scripts written by a kid who barely knew Perl, but just enough to get things done. He released these as "Matt' Scripts". The Perl community worked long and hard to remove these from coming up as 1 on Google... with a site called Not Matts Scripts and the perl files called nms
that when user activates it the usual way (like a button), they then get moar tabs above (the first ones go offscreen) and focus back to top, to these new tabs?