To Hell with Performance by Karl Groves
This is the second talk in a set of three talks on Accessible Performance delivered on April 1, 2016 at Fronteers Spring Conference in Amsterdam
There are scores of concerns, both back-end and front-end, when considering performance. When it comes to accessibility, user performance is also a major concern and extends beyond things like perceived time. While perceived time is very important for UX, accessible user experience intersects performance in that it requires allowing the user to answer one core question as they work with the interface: "What is this thing, and what does it do". In this talk we'll talk about the intersections of UX, performance, and accessibility and how each contribute to an accessible user experience.
(presenter) So yeah, we'll see you in a few minutes for that.
So, let's rattle straight along.
We're-- we're continuing on this theme.
These talks seem to be following-- No, I don't think this has happened by accident.
I think these are being curated quite carefully as we build on this theme of accessibility.
We're going to talk-- we're gonna hear, rather, from-- from Karl Groves in second, who's got a lovely title for his talk, "To Hell with Performance", so who knows what kind of shenanigans we're going to be up to here.
But Karl works at "Patch-iello" group-- Paciello group, I'm sorry, I knew that I'd botch that-- in Washington, DC.
Helping companies do a better job of accessibility and performance.
Has built tools on that to help with this, and does various courses on this subject.
So let's hand straight over.
Karl Groves, everyone.
So I got this invite to talk here, and I was extremely excited.
And-- and I was willing to talk about just about anything.
They said well, the theme is going to be performance.
So we're going to-- we want you to talk about performance and accessibility.
I was like, cool.
No-- no problem.
And then, you know, I took my sweet time figuring out exactly what I was going to talk about.
I looked at the descriptions of the talks and I saw Marcy's talking at the-- shit.
She's already saying all the good stuff.
You know, I'm like, what am I going to say that's different? And then I saw the date and it's April 1, and I'm like yes, to hell with performance.
They're gonna love it.
I'm going to make friends.
But first, who thought it was a good idea to invite a former philosophy major to do a 20 minutes talk? I had to remove about 10 slides with meaningless inspirational gibberish, 15 slides bitching about the NS, and 30 slides dedicated to cheese, marijuana, and sex museums.
So I guess I'd better to get to meat.
It's the only Dutch word I know.
And don't ask me for pronounce it because I-- I don't have any phlegm in my throat yet.
So really, who gives a shit? That picture, by the way, I've been waiting to use that for a long time.
It's a truck full of donkeys.
So this person's literally hauling ass.
But really, who cares? Well, actually, our customers care, OK? And so if we're talking about performance we can all pat ourselves in the back and say yes, I shaved off a couple milliseconds.
But the reason why we want to do that is because our customers want that.
I'm a-- I'm-- I'm American so I'm a shameless capitalist and I like money.
A one second delay in web page responsiveness led to a 7% decrease in conversions, an 11% drop in page views, and 16% decrease in customer satisfaction.
After three seconds, 40% of those potential customers will abandon your site.
So really, if we're really going to talk a lot about performance today, we're really talking about doing a good job for our customers.
Because the customers buy our stuff, and then developers can pay our salaries.
So let's talk a little bit about my personal love affair with performance.
Several years ago, probably long before many of you guys were out of school, I-- I had the opportunity to work on a site that had a little bit of a adult nature.
And-- and I was relatively new to performance, because I'd never really worked on a site that had a lot of traffic.
If you happen to have popular content of an adult nature, you learn a lot about database indexing really fast, because we happen to have a lot of referral traffic come in.
I have no idea why or from where and it didn't really matter because we were talking about money.
And it was just get-- the server was getting hammered, and I had to learn a lot of database indexing then.
And then I created my own product, and we have 3,000 users on this product, which isn't-- we're not Uber or anything like that.
But there's lots of resource-intensive operations going on on this product where-- we're doing-- we're talking about-- we have a million logs so far.
We've logged over 30 million individual issues.
The database obviously is growing very massively, so then we're starting to talk about sharding and load balancing and all that sort of stuff.
So I have a little bit of experience with performance but not so much on the front end as a lot of you guys have.
My experience is mostly in the back end.
But when we're talking about performance, I think about why can't we just add accessibility into this mix when we're talking about customers who bail? There's very real reason to continue to care about customers with disabilities who may bail as well.
And this quote comes from a brick and mortar, a traditional physical web study of people at stores and stuff like that.
But I think that there's probably a strong correlation with technology as well.
Looking at this across impairment, the percentage of people who've left a business due to accessibility problems can reach 83%.
So that is a ton of people, and we should care about them as well.
So I started thinking about that from a performance perspective, and I wanted to teach people a little bit about accessibility.
And there's lots of resources out there.
As a matter in fact, the Wicket standard itself is 36 pages when it's printed out, and the how to meet documentation is 44 pages.
So you have the standard and they tell you how to meet it and that's longer.
And then, hey, if that other shit didn't do it, let's add 230 more pages to the mix, understanding Wicket.
And then there's the techniques and failures.
So I'd really have a better idea about that when we're talking about accessibility.
Let's teach device designers and developers to do one thing.
Always ask, what is this thing and what does it do? Forget about the 1,000 pages of stuff.
What is this thing and what does it do? Because that's what the user is actually going to be asking when they get to the page.
They want to know, where am I? What can I do here? How do I do that? And if I made a mistake, how do I fix it? And Marcy talked about some of this stuff when she was talking about using the regular select element, right? Because you get that accessibility for free.
Once you've gotten to that control, the user's going to ask themselves, what is this thing and what does it do? And some of that stuff comes for free.
And she also talked about the performance stuff on the CNN page loading.
And a lot of the information the screen reader's going to read out is going to tell the person where they are.
And so the first thing it reads out as the title tag, and then it's going to start reading the percent loading that she showed.
But after that clip, what else is this gonna-- it's going to tell you is how many links are on the page.
How many headings are on the page? How many frames? How many tables? All that sort of stuff.
That information that, in a badly performing site they're not going to get until all that stuff is loaded, because it's going to need to use that information to get there.
So from a user experience perspective, from the user's performance, right? They-- they're-- we're really talking about what's known as the principle of least astonishment.
Basically, a person should be able to look at something and immediately intuit what they're supposed to do when they get there.
But if you can't see, you can't form that cognitive model of what's on the screen, you're going to have a hard time.
Anybody know what this is? Really.
It's a front end conference.
OK, its a drop down.
So what does it do? You click and select one, right? That's it.
Is that all a select element does? No.
So the HTML select element represents a control that presents a menu of options.
The options within the menu are represented by option elements, which could be grouped by off-group elements, obviously going to be preselected for the user.
Tab moves focus into the field.
A second tab select the current item on the list, updates the field's value, closes the drop down list, then moves focus to the next focus-able item in the tab order.
Alt and down arrow and or space opens the drop down list and moves focuses selected option.
If nothing is selected, the focus moves to the first option in the list.
If the combo box is not editable-- I'm really sorry to the-- then the spacebar-- my cells would be used to open drop down list.
Up and down arrow moves focus up and down the list.
As focus moves inside the drop down list, the edit field is updated.
Enter selects the current item on the list, updates the value, highlights the selected item in the drop down list, closes the drop down list, and returns focus to the field.
Escape-E closes the drop down list, returns focus to the field, and does not change the current selection.
Typing a letter- a printable character-- move key moves focus to the next instance of the visible notice whose title begins with that printable letter, and it exposes these roles to assisted technologies.
So-- I like, huh.
You don't say.
So let's look at a really popular jQuery plug-in.
As a matter of fact, I should probably plug in the audio first.
All right, we'll start over.
Black pop-up button.
Menu 252 items check mark.
United States, United Kingdom, Afghanistan, Aland Islands.
Afghanistan, United Kingdom, United States.
close-- So that's the standard select element, demonstrating all those things I just read rather rapidly.
United States pop-up button.
You are currently on the text field.
Ha Ha, April fools, Mr.
Assistive Technology User.
Black pop-up button.
All right, so that's chosen, the jQuery plug-in the team, unwieldy select boxes by replacing it with something more unwieldy.
So another thing that the people need to know when they get to a site or interact with stuff is, what's happening.
Like, I'm now interacting with something.
I need to know what's going on.
What's the result of my action? So this is an example of ARIA live regions.
I-- I don't know if anybody here knows what live regions are.
Anybody know where live regions are? OK.
So live regions are really cool piece of technology, because they'll be-- they'll tell you-- they'll be a tell you information on the screen that may have been added or changed, separate from where you currently have focus.
If you're on a screen reader, as you to tab around is you get to the different pieces of the content.
It reads what has focus.
But if you're doing something else-- say, sorting a table-- then you have no idea what has happened without being told.
So this is actually a-- I use this example as a web components talk.
But one of the things that is here is this-- this live region here.
And so the live region I've applied to the caption element, it's got a ARIA live value asserted, which means any time that content changes, it's going to be read out to the user.
And so at the other parts here are relevant to making that live region work.
But what's great about this then is now we have an opportunity to tell a user what's going on.
Voiceover on Chrome.
CSV dash preview window.
Cool table, , bro sorted by first name descending.
You are currently on a cool table, bro, sorted by first and last email.
Cool table cool table, bro, sorted by email ascending.
You are currently on a cell.
It-- voiceover off.
It's very painful for me listen to Voiceover that slow.
It's usually much faster.
But we need to be able to tell the user what's happening, especially if that content has come from Ajax or something like that.
Because we have to-- if they have to wait for something to-- to load, then they're going to need to understand what's happening there.
So here's another example of that.
Voiceover on Chrome.
Ajax loading load content loading, please wait.
Alert main one item.
You are currently on alert.
To interact with items in this group, press control.
Main two items.
You are currently on a group.
So when you present something with the role of an alert, it's automatically treated like an ARIA live region, which is great because-- when you saw when I put that overlay on there and had the loading image, it said please wait, content loading.
We're telling the user what's going on so they know that they can wait around, and hopefully we're going to tell them what has happened or redirect them to the new content.
And that's really vital in cases like, let's say we have a web store that allows us to filter our search results.
And so you filter your search results.
You have to make another round trip to the server to get the new products.
And when you update that content, tell them you updated it.
And that's really all that really-- you know, when that case really need to do.
Another thing that we want to do is, that we can tell them what has happened.
And this is really important for use cases that are on form-driven workflows where we need to give the user the ability to recover from error.
Because one thing that I've noticed in many, many, many usability studies is that a task it takes a non-disabled person a couple of minutes, can take a person with a disability 10 times as long.
I'm making that number up, but you get what I'm saying.
If they can't recover from the error because they don't know what the hell has happened, then we're gonna-- we're doing them a little bit of a disservice.
So here's an example of a form field validation I'm just going to-- I'm just going to enter the form with no information in it.
Voiceover on Chrome.
Three errors are preventing successful submission of this form HTML content.
You are currently-- voiceover off.
As, you can tell I am quite a skilled visual designer.
But this is another case where we've detected our errors.
And if you can do form validation, you can tell them what the hell happened, right? Every-- a lot-- this is something a lot of people forget about is that if we know, for instance, that you have not entered a valid phone number, tell them.
Don't say this field needs to be fixed.
Tell them what's going on.
We shift focus directly to the error message.
We give that a role of alert.
It gets read aloud allowed assertively.
And then we give them links directly to the information that has been found to be in error.
And then adjacent to each field, using ARIA described by, we tell them what the problem is.
Please enter your last name.
The other really cool thing is, imagine this is a much more complex form, and you have filled in some of the information.
You know what the next error is too, don't you? Because you've done the validation.
So tell them.
the next there is state. .
Boom And then you jump to that screen.
And then, the other thing I want to impress upon people is just make it accessible I-- I love this video because it shows-- what I want to do is pay attention as it plays, to where focus happens .
Because one of things that the day they've done that is harmful to performance, is that they cause a-- they cause a round trip to the server every time you change radio buttons, which results in what I affectionately call hocus focus.
Flights and airfares.
Flights and airfares.
Selected radio button one of three.
Selected radio Virgin America.
You are cur- you are current link.
Good old unchange.
Selected radio button two of three.
You are cur-- Multi city.
You are cur-- You are-- Link.
Navi-- And what these guys have done actually is, if-- if you, if you were able to see the full URL, like in Chrome or something like that, what they thought that they've done is, when the page loads they want to shift focus to the next relevant thing.
So when you select what trip type you want, it goes from round trip to one way, blah, blah, blah.
And they try to shift focus to it by using a named anchor.
The problem is that the round trip to the server and back takes so long that the user's actually tabbed past that already, OK.
So they've already circumvented the-- you know, what they've done is they've made this assumption that you're going to just going to sit around and wait.
Well, they haven't told you what you're waiting for.
They haven't told you that anything has shifted focus, or they haven't told you that new content has been introduced.
So you're just like, shit, I gotta start over again, and start over from the top of the page.
They could have just made it accessible in first place, I think.
Anyway, at the end of all of my-- all my talks, I, use this slide or another one.
But basically the same thing.
Anybody here interested in wood working at all? OK, so that's a dovetail joints.
A dovetail joint is especially strong, both mechanically and because it allows you to put-- you-- to glue long grain to long grain.
If you glue two pieces of boards together, end to end, that's end grain to end grain and it's a really weak joint from a glue prospective, too.
Long grain to long grain is the strongest way to glue wood together.
So not only are dovetails mechanically strong, and enhanced by the glue, but also they're attractive, too.
And I feel very strongly in the idea that good design is a convergence between creativity and capability.
I'm Karl Groves, and there's my information.
(presenter) First off, thank you, Karl.