Transcript

 CHRIS:    Hello, everybody!  Thanks for listening to Shop Talk Show.  This is Episode #141.  We have two sponsors for you.  Environments for Humans are doing this JS Summit, probably their biggest, baddest, most revered online summit there is.  Go to JSSummit.com.  It's three days.  You can attend it from anywhere in the world.  Use SHOPTALKSHOW as a code when you're checking out if you plan to attend the JS Summit, which you should.  And Lynda.com/ShopTalk --

DAVE:   L-y-n-d-a dot com.

[Laughter] 

CHRIS:  Thousands of courses on there.  The biggest learning resource there is on the Web.  You get a free week if you go to that URL.  Go to /ShopTalk.  Yeah, we'll tell you more about both those things later in the show.  But for now, lets kick things off.

[Banjo music - intro]

DAVE:   Hello there, Shop-a-maniacs.  You're listening to another episode of the Shop Talk Show, a podcast all about front-end Web design and development.  I'm Dave Rupert, and with me is Chris Coyier.

CHRIS:  Hello, everybody!

DAVE:   Live from the shed.

CHRIS:  Live from the shed.  We are indeed, for the second time in recent history, together on Austin, Texas, in Dave's shed.  I'm in town because later today, which if you're listening to this through the podcast, you know, it'll be already over, but if you're listening live and happen to be in Austin, come down to Bungalow tonight.  It's the inaugural, first ever … meet up.

DAVE:   A little party at the Bungalow.  

CHRIS:  Yeah, it should be good.  And we have with us Marcy Sutton.  Hey, Marcy.

MARCY:  Hello!

[Ta-da orchestral fanfare sound effect]

CHRIS:  Thanks for joining us.

MARCY:  Good morning.  

CHRIS:  Yea!  We have a whole --

JARED:  Yea!

CHRIS:  We have a --

[Laughter]

DAVE:   Up early in Seattle.

MARCY:  Yeah, a little bit.

DAVE:   Good morning, Seattle!

MARCY:  Good morning, everyone!

CHRIS:  I have Marcy on to talk about all things Web, but you have a bit of an accessibility bend to the work you do.  Is that right?

MARCY:  I do.  It adds a lot of meaning to work that sometimes would not be that exciting, although my current project I'm pretty excited about, which is Angular Material, which is a set of components that I'm getting to make more accessible.  

CHRIS:  That's pretty sweet.  They were existing components, and they're like, we better bring somebody in to make sure that we don't screw this up, and that was you?

MARCY:  Yes, and there are new components that haven't come out yet, so I get to actually fix them early in the process instead of having to clean them up later, which is always ideal.

CHRIS:  Nice.  When you say components, are they literally Web components--we've talked about that a little bit before on Shop Talk Show--or does Angular have its own idea of what a component is?

MARCY:  Technically speaking, they are not Web components yet, but I know the next version of Angular, they are talking about it will have Web components integration, so in the future it might become more that way, which I was happy to hear about.  But for now, they are just -- it's like instead of using jQuery UI, you could use Angular Material and then have designed a widget.

CHRIS:  Yeah.  Name a few of them.  Is it like accordion?

MARCY:  Like checkbox and radio buttons and--let's see what else--tabs, tab switcher thing.  The idea is that there's a common design language across all of these components that has been well through out by the Google design team.  

CHRIS:  Mm-hmm.

MARCY:  There are lots of ripple effects and fancy things that have a lot of UX thinking beyond just, you know, the nuts and bolts of the actual component.  

CHRIS:  Mm-hmm.  Cool.  Components, just, you know, I guess, a generic word.

MARCY:  Widget.

CHRIS:  Another name for a design pattern.  Yeah.

MARCY:  Or widget.

CHRIS:  A widget, that's the best one.  Let's just call them widgets.  

MARCY:  Yep.

CHRIS:  Yep, and is it the same?  If these weren't Angular components, they're still built in.

MARCY:  In JavaScript and CSS and HTML.

CHRIS:  And HTML.

MARCY:  Yep.

CHRIS:  So ARIA roles still are a thing.  It's the same.

MARCY:  Exactly.  Yeah, so it's pretty cool as an accessibility engineer to get to go in and add ARIA to these things, but I'm always weighing, like, are we over-engineering this thing too?  Can we just use a native button, because that's a lot easier, and it's a lot better?

DAVE:   Yeah.  Why does Web components hate buttons?

MARCY:  Yeah.

DAVE:   That's my number one question. 

MARCY:  Because you could have a super button that delivers you tacos.

DAVE:   Ah!

MARCY:  A have a JS Conf talk where I actually made a Web component button that delivered real life tacos, and that is the Internet realizing our dreams.

CHRIS:  Did you really?  Tell us more about it.

MARCY:  [Laughter]

DAVE:   Yeah, this is actually relevant to my interests.  You've really hit the niche.

MARCY:  Taco button.  

CHRIS:  Yeah.

DAVE:   [Laughter]

MARCY:  Taco button, yeah.  At JS Conf, I did a talk on accessibility of Web components, and you can watch the video.  But I had a button that basically I wanted to test, like, really basically could a screen reader interact with a Web component because Shadow DOM does some tricky things where it encapsulates styles and scripts so that you don't pollute outside of this Web component, like your H1 styles don't affect inside of the component and all that kind of thing.  So I was curious for a screen reader what would happen with a Web component.  So I made really basic components just to test that the keyboard could go past that boundary and all that kind of thing.

    But to make it more fun, my button that I tested, originally when you clicked the button, it would just append taco gifs on the screen, and it was kind of funny.  But we were, you know, networking around the pool at JS Conf.  There may have been some drinks involved.  

CHRIS:  Yeah, pool conf.

MARCY:  Yeah, pool conf.  And I thought, what if that button could deliver real tacos?  Over the next few days, I found a way to make that happen.  The hotel catering, Twilio, I hooked up the button to make phone calls, so I actually called Angelina --

CHRIS:  This is not theoretical.

MARCY:  No, this is literally I had Angelina Fabbro in on it, and she expensed the tacos, so Mozilla paid for the tacos.

DAVE:   [Laughter] So --

[Laughter]

DAVE:   You robo-dialed the hotel catering for tacos?

MARCY:  Yeah, pretty much.  

DAVE:   Sweet!  They get a call, "We need tacos."  

MARCY:  Yeah.  Yeah.

DAVE:   "In the conference room."

MARCY:  And Angelina came in and said, "Don't use this power very often, you guys, because it's really tiring."  

[Laughter]

DAVE:   Oh, my goodness.  

CHRIS:  That's part of the deal with Web components; the Shadow DOM is one of the ingredients of Web components, right? 

MARCY:  Yeah.

CHRIS:  It could have been poorly implemented.  It could have been: you can't even tab inside of this thing.  

MARCY:  Exactly.

CHRIS:  Who knows how poorly it could have been done, but did it turn out that -- I don't know?

MARCY:  They had thought about it?  [Laughter]

CHRIS:  Yeah.

DAVE:   That's how it, like, broke down for me from the outside.  You know, Google is ready to ship Web components and then it seemed like you were the voice who said, "Hey, have you thought about accessibility?"  And they were like, "Whoa!  No.  Hold on.  We need your help." 

MARCY:  Yeah.

DAVE:   I guess, how did you get involved in that?

MARCY:  Yeah, unfortunately that happens a lot.  I was kind of just an outsider, and I started asking questions and wondering, and I saw there was not much research in that area.  And so I just started writing those components and testing them.  Fortunately, they had thought about it, and so I joke around, but I didn't have to go beat anybody up.

But I figured if it was early enough, like normally you go to a conference.  You hear about something like Shadow DOM.  You're like, oh, I'm not going to be able to use that for at least three years.  

Well, if you actually go and play with it earlier, you can find bugs and potentially actually you could change the outcome of that technology earlier.  So I figured if I started playing around with it and there was a problem, I could get on a mailing list or get involved in some way.  But I didn't have to because it worked.  It was successful.

DAVE:   Cool.

CHRIS:  Like 100%?  Like, you just gave it the thumbs up, like, oh, we did it?

MARCY:  Pretty much.  Yeah, there was no gotcha at that time.  I think there are some tricky things with ID references inside and outside of a Web component and there might be --

CHRIS:  Oh, I supposed.

MARCY:  -- there might be some tricky things there, but as far as trapping focus and communicating inside and outside, there are ways that, you know, it's supposed to be encapsulated.  But in terms of a screen … and a keyboard, it's just a seamless interaction as long -- there's a caveat though.  It's as long as you make accessible code, which is true regardless of whether you're in a Web component.  

CHRIS:  Right.  You can screw it up in the same way that you can screw up anything else.

MARCY:  Exactly, so the same principles apply, which actually ended up providing an accessibility platform for me to actually go and remind people of things they should have known already.

DAVE:   Cool.  I guess, do you find it easier to work on kind of the Web component, that component level than kind of like, let's say, in your client work, given a website and saying, hey, make this accessible.  Is it easier to do it on a component-by-component basis?

MARCY:  I think, if you build modularly, that things get easier, but you learn things from both.  I learned everything I needed to know for Web components by doing client work and making websites accessible.  But I like the thrill of the kind of forward thinking technology research, so that's what I want to do more of, but I had to start with the client work and doing things for Target that had to be accessible.

DAVE:   Hmm.

CHRIS:  Ah.

MARCY:  I recognize where all of the --

CHRIS:  Target.com?

MARCY:  -- all of it came from.  I worked on Target.com.  We were not the primary vendor for that, which I am grateful because that site was very hard to get right, but the corporate site, we were responsible for at POP.  

CHRIS:  At POP.  And now you're at Substantial.

MARCY:  Yes.  

CHRIS:  Both are Seattle --

MARCY:  Yep.  Substantial is out of the San Francisco office, and I think they are hiring.  If you're interested in checking it out, it is Substantial.com.  

CHRIS:  Hmm.  Chi-chi.  

DAVE:   Yeah, where's my cash register?

[Cash register sound effect]

[Laughter]

DAVE:   All right.  

CHRIS:  We'll send the bill.  No, just kidding.

MARCY:  No.

CHRIS:  Which one was hiring?  Substantial is?

MARCY:  Substantial.  I think POP might be for designers.  I went to Substantial personally to learn software testing and Agile and just a fundamentally different way of working because, for me, every few years, I like to learn new things because I feel like I'm not able to in my daily job.  Now I use those skills on Angular Material writing tests, collaborating over GitHub, so that ended up being a very good move for me.

CHRIS:  Right, because even though we said the Shadow DOM largely gets the thumbs up, but still, the things that you build inside of it, these components you're building still need to be thought about and a thumbs up.

MARCY:  You still need good, you know, Web development practices.  

CHRIS:  Yeah.

MARCY:  The thing I'm excited about these days is trying to get automated accessibly testing and coverage in your code base so that I, as a contributor, go and write some code that's accessible, if somebody else breaks it, they could break the build because I have test coverage for all of these things, unit tests.

CHRIS:  Nice!  I haven't even thought of test coverage for accessibility things.  What is an example of something that passes and then breaks?

MARCY:  Yes, so the kinds of things that we test are, for example, in Angular Material, we have a set of radio buttons.  The way that the radio buttons have these ripple effects and kind of interactions between them means that we made a custom control, so we're basically mimicking what a native radio button does, but with a custom control.  You can debate all day of whether that's a good idea, but it's happening.  The ARIA for that is not too complex, but the unit test coverage basically has to assert that this component does what you would expect a native set of radio buttons to do, including the arrow keys.  

The pattern for a radio button group is that you tab onto it, and then you use the arrow keys to select between them.  You can write a test basically mimics this behavior and then will give you the green thumbs up when everything is good.  If there's something wrong with it, maybe somebody introduced something that broke that pattern, then there's a test that would warn them that, hey, you broke this.  Just so you know, you're a jerk.

CHRIS:  What is the test written in?

MARCY:  It's all JavaScript.

CHRIS:  Okay.

DAVE:   Like Mocha or Jasmine or something?

MARCY:  Exactly, yeah.

DAVE:   Okay.

CHRIS:  Neat.

DAVE:   Then it runs the behavior kind of automatic, robo checks off and tries to navigate, and it should pass everything.  

MARCY:  Yeah, so you can basically stub the keyboard event, so you don't have to fire a real keyboard event.  I've been on projects where we have a Jasmine test page, and there's keyboard events running, and the page is jumping around. You don't actually have to do a real keyboard event.  You can mimic one.  I usually have a utility, you know, some JavaScript file with utilities in it, and you can -- I know you can have a jQuery -- just mimic a keyboard event and then pass the key code through to check: was that the right arrow?  Okay.  Was that the left arrow?  Did it do what it said it was supposed to?  I find those kinds of tests help a lot.  They strengthen your code base quite a bit.  

DAVE:   Then I assume you could do the same thing with, like, modals, like if you pop open a modal, does it have focus and stuff like that.

MARCY:  Exactly.  Yeah.  Did focus get sent into the modal?  You could one step further and say, you know, is the rest of the content disabled?  Am I unable to get back to it?  Because that's what a modal --

DAVE:   Mm.

CHRIS:  Mm.

MARCY:  -- modal is supposed to do.

DAVE:   Oh.  

CHRIS:  Whoa.

MARCY:  That's what the native modal element does, but it's not supported very many places yet.

DAVE:   Yeah.  

CHRIS:  Where does it put you back after you escape out of it, I suppose, is the thing.

MARCY:  Yep.

CHRIS:  Wow!  Testing accessibility.  

MARCY:  Yeah.

CHRIS:  I forget the whole thing.  I didn't even think.  

DAVE:   Is there a library that you use, or do you kind of cook these up for each and every situation?

MARCY:  For Material, it's pretty custom for each widget.  But that's definitely something I've got my eye on to see what kind of resources are available because that's the unit test level.  That's like each widget we write, we write tests for that.  I think there's probably some end-to-end testing like integration testing where you test everything together.  That's something that I haven't done as much of that seems important because sometimes it's like the individual component will work, but maybe it doesn't work with the rest of the page or there are things that we didn't catch because we don't have full integration testing.  That's a topic I'm just starting to look into.

CHRIS:  Just back up one step.  I'm curious of, like, let's say that you make a slider, a Web component, and the slider has left and right arrows and this type of stuff.  Then you're outside of it if you're where the control is.  You're tabbing through a page, and then you come upon this slider that's a Web component.  Does the tab -- how does tab index work, essentially?  Does it just hop in that Web component and let you tab all the way through it, and then hops out when, I guess, the document of that slider Web component has ended?  

MARCY:  Yeah.  Specifically, well, the Web component, it just adds another tree into the rest of your DOM, so it's pretty seamless as far as the keyboard is concerned.  But the pattern for a slider, I think you tab onto it, and then you hit the arrows.  If you tab again, you just tab onto the next element.  It's important to look at what the expected behavior is for a specific component like tabs or a slider, so I generally will look up the ARIA role for slider, even if it's just to inform.  Like, if it's already a native element and I might want to go look: What is the expected behavior for a keyboard user?  That's helpful information to know if you're actually creating these user interface patterns.  

CHRIS:  Yeah, I see.  You'd have to -- you would tab to the slider as a whole, and then you would, as the keyboard user, you would choose to enter slider land or yet another tab would just--?

MARCY:  …I think you're automatically on it if you tab onto the slider.  Tabs are a unique beast in that, to activate a tab, you actually hit the enter key or spacebar to show the content.  

CHRIS:  Mm-hmm.

MARCY:  That's the way we're doing tabs.  But for a slider, you just tab right onto it and use the arrow keys.

CHRIS:  Ah, okay.  Yes, so interesting.  All right, so Seattle, and I think I just have generally notes before we jump into the Q&A.  You are a biker, big time.

MARCY:  I am a big time biker, yes.  

CHRIS:  Yeah.  Seattle accommodates your --

MARCY:  [Laughter] Yeah, I've gotten hooked on a little thing called cyclo-cross, and actually, this last week, I went to NG Europe and Paris, and I brought my bike with me, which was amazing.  Highly recommend doing that.

DAVE:   All right, well, let's maybe hop into some Q&A, the meat and potatoes of the Shop Talk Show. 

CHRIS:  Mr. David Clark writes in, "Well, I can certainly follow instructions and match examples.  It would it also help to be able to test.  Do you know of any standard way that accessibility aware Web developers will test if their ARIA related efforts have proven successful?  Is there some screen reader or browser extension of choice for your personal recommendation?"  David is in that place where he's interested in accessibility, and it's one thing to look at some blog posts and see what it says about accessibility and try to match what they're doing, but how do you kind of ensure that what you did was useful, was the right thing?

MARCY:  Yeah, because sometimes it's hard to tell if you're not a screen reader user.  I have started using the Chrome accessibility developer tools, which is an extension for Chrome.  There's also the Web Aim toolbar.  They recently received a Chrome version, I think, for their 15-year anniversary for Web Aim.  

DAVE:   Yeah.

MARCY:  Which has Web accessibility in mind.  But lately I've been using the Chrome accessibility tools because they run a set of tests, all the kinds of things like making sure that ARIA roles are used correctly and that all of the required attributes for a role are present, and you get red, yellow, green warnings with levels, visual levels of, hey, this either passes or fails a certain test.  And it's testing your specific code, which it can be something you're just running on a local host, or it could be a remote site.  It's pretty useful information because it will tell you exactly where in your code the problem is.

CHRIS:  Nice, so there really are some good tools.

MARCY:  There are, and I think there's a command line version of that you can actually --

DAVE:   Automate it?

MARCY:  You could potentially automate that.  There's also Tenon, which is a product that my friend Karl Groves is making.  Tenon API is in beta right now, and I think the goal of that is to give you a set of tests that you could run, you know, in Grunt, along with the rest of your test suite, so it would just automatically check for you.

CHRIS:  Nice.  I suppose there's no substitute for actually trying to use your own site.

MARCY:  True.  Yeah.  I feel like you could catch some of the more basic things, but you should still go and make sure it's a good experience.  

CHRIS:  Yeah.  We had an interesting one.  I was talking with Derek Featherstone at a conference recently, and we were talking about one of the challenges of keyboard use on CodePen is that the text editors themselves eat the tab key because pressing the tab key when you're in a text editor inserts the tab.

MARCY:  Yeah.

CHRIS:  You can't get out of that, and we want that behavior because that's reasonable.  What you should be able to do is hit Esc to get out of it.

MARCY:  Yeah.

CHRIS:  Which is nice, but then when you reenter that area, it should take you back to where you were, so you shouldn't be, like--I don't know--penalized for leaving it.  You should be able to hop out and hop back in of that area.  That was Derek's idea of how to handle it, and that's not natively how it works right now, but it's just some custom code that we would add.  And there's no tool that we could click a button to tell us to do that.  

MARCY:  No.

CHRIS:  Somebody had to think about that.

MARCY:  Yeah, that's a more complex interaction because you're basically mimicking a desktop application in that text area, which there are roles in ARIA that we tend to tell people to avoid because they're more advanced, but that is a more advanced scenario where you should consider maybe the application role or you're going to need some custom JavaScript to make that interaction a reality.  But I think there are some basic things that people forget, like using headings correctly or using native elements wherever possible.  There's a whole spectrum of accessibility, so it is cool to think about those more advanced patterns that are probably original.  I haven't heard of that one before.

CHRIS:  Yeah.  It's tough.  I think different coding applications have had different styles.  One of the styles is just don't allow tab to be pressed in which to indent.  You know, just tab takes you away from that text area and onto the next thing.  If you want to indent code, you can use the spacebar to do it.  That one felt weird to me because I feel like we're so used to using the tab key for that specific purpose when writing code.  I didn't want to take that away from people.  

MARCY:  Yeah, it's like you need a mix of both.  

CHRIS:  Mm-hmm.

MARCY:  It's a desktop application in the Web.  

CHRIS:  Yeah, and now I'm a little obsessed about it like where does tab take you next?  And then when you leave it, where do you go exactly?  Is it really easy to hop from editor-to-editor because right now it takes -- this is on code, but I know this is so specific to me, so we'll move on to more generic things, certainly.  

DAVE:   No (indiscernible).

MARCY:  [Laughter] Many of us use CodePen, so it's not just you.

DAVE:   Yeah.  But this is a good challenge.  This is a real world, like --

CHRIS:  Yeah.

DAVE:   -- I made this thing.

MARCY:  Exactly.

DAVE:   How do I make it accessible?

MARCY:  Yeah, and how do you make it a good experience, because you get to--?  Like, you actually get to innovate and define what is a good experience for a keyboard user, which is cool.

CHRIS:  But in those same lines, it's like if there already is an expected behavior that we could just get for free by applying a role to, we should do that, right?

MARCY:  Yeah.

CHRIS:  It's like reinventing the wheel sometimes is a bad idea, right?

MARCY:  Well, the wheel has, you know, it's like two wheels in one.  It's a very complex wheel, so it's hard to automate or anticipate every scenario when they're so custom.

CHRIS:  Mm-hmm.  Cool.  Let's see.  David, we will put links to all those things in the show notes: the Web Aim one, the command line tool one, the Chrome add on.  

DAVE:   The Chrome add on is cool.  I just ran it on the Shop Talk site.  It feels pretty good.  I mean it's a really basic site, but a lot of the errors are WordPress admin stuff, like that little toolbar, so it sounds like somebody could fix that up for somebody.  

MARCY:  [Laughter]

DAVE:   All right.  Cool.

CHRIS:  Let me do a sponsor.  We're 30 minutes in here.  We have the JavaScript Summit coming up.  That's coming up fairly soon, as you're listening to this.  It happens November 18th, 19th, and 20th.  It's a three-day.  It's kind of their, possibility their biggest summit.  We say summit as it relates to Environments for Humans conferences.  That means they're online conferences.  You can attend it from anywhere in the world where you have a computer and an Internet connection because you sit wherever you are and watch the conference.  It's still a live event though, right, so there's a chat room, and you're listening to the speakers speak live and speak.  It's not like you're just downloading a video and watching it.  This is still a live event that everybody attends at the same time.  It happens from 9:00 a.m. to 4:00 p.m. central time, so however that adjusts to where you live.  You know, it's central.  It adapts.

DAVE:   It's central.  It's the middle.  

CHRIS:  It's the middle.  Tons of speakers talking about all things JavaScript.  This is their unmissable one.  This is the one that you want to attend to.  

Totally jealous of all this stuff: Mark Urbaski talking about SVG.  Dmitry Baranovskiy from Snap.svg talking about Snap.svg.  Pam Selle talking about choosing a JavaScript framework.  There are too many to list, people from big companies talking about how they do things for real, talking about performance.  I wouldn't doubt there are some good accessibility stuff that gets talked about that day because that's just always a topic.

Anyway, check out JSSummit.com.  That'll redirect you where you need to go.  Use coupon code SHOPTALK for 20% off.  

DAVE:   Awesome!  All right, well, we got an audio question here from Scott Fennel.  Here we go.

SCOTT:  Hey, guys.  This is Scott Fennel in Anchorage, Alaska.  I've got a question for you about WCAG AA 2.0 guidelines.  We have a client that wants to be a WCAG valid, and they believe that in order to meet that, they need to have valid HTML, as in a green square from the W3 validator machine.  We don't think that's true.  We read the spec a little bit differently than the client is, and I was hoping to get your opinion on this matter.

CHRIS:  All right, so do you have to pass validator to pass WCAG?  Marcy?

MARCY:  That is a good question.  I am of the camp that you don't have to validate just because there's so much experimental stuff going on, but I know that the HTML 5 validator has caught up.  There was a period where nobody validated because, like, media queries and things and line were not valid.  But I think the HTML 5 validator has caught up quite a bit.  I mean, it couldn't hurt to go look.  You know, go see what it fails on, and then have a conversation about those specific things with your client.

CHRIS:  Yeah, right, like if there's actually an error in your HTML, you might want to fix it.

MARCY:  Well, and maybe it's a thing where it should be something you can validate.  I would say I'd probably meet them in the middle and do it anyway and see what it fails on, if anything, and then go mitigate those specific things.

CHRIS:  Scott didn't mention in the recording here, but he wrote what the error actually was below here, and he said that it was small chunks of style tags in the body.  I think that causes an error because style tags should be in the head if you're going to use them.  But I think, as most of us know, you can put those pretty much anywhere you want and the browser will read and interpret them and not have any trouble with it.  It's weird.  It kind of seems like why was that necessary to be in the body.

MARCY:  It is weird.  

CHRIS:  Maybe it's a CMS thing.

MARCY:  Maybe -- yeah, exactly.  It's probably a CMS.  It might be third party things that you can't control like, I don't know, if you use a Facebook like button.  That injects a bunch of stuff into your page.  It could be -- yeah, it's hard to say.  I would definitely go just look at that stuff pretty closely.  Look at the sites that you have to support.  I'm guessing if they're going for WCAG 2.0 AA that they maybe have an older suite of browsers.  So I would go see how that -- is there any lag in rendering in an old browser.  Maybe that's why they're trying to cover that, but yeah.  

CHRIS:  It could be.

MARCY:  As much as I don't want to validate, I think, in that case, you probably would want to go look at it a little closer.

CHRIS:  I'm curious about, like, you know what's invalid - MG attributes.  That's not a valid attribute.  

DAVE:   [Laughter]

CHRIS:  How does that relate to something like Angular?

MARCY:  That's true.  Well, Angular only supports newer browsers.  But, yeah, it's definitely not a state of mind where people are validating anything because they will -- you know, something I commonly have to deal with for accessibility on that project is overuse of HTML 5 attributes like disabled and required, which don't actually work on custom controls.  The required attribute was made for a form element like a button.  Button wouldn’t be required, but an input or checkbox or something.  But we have custom elements that are basically like divs, and if you stick the required attribute on a div, it doesn't actually require anything to a system technology.

CHRIS:  Right.

MARCY:  You might be able to style that, but you aren't telling a screen reader that it's required or disabled, so I bet that a good validator would catch something like that.

CHRIS:  Yeah.  Good point. 

DAVE:   That's interesting.  Like div required doesn't do anything --

MARCY:  No.

DAVE:   …fix.  

MARCY:  MD-input, you know, which is the tag name for material design input, that's essentially a div.  Web components like custom elements are essentially divs too if you don't add semantics.  

CHRIS:  Right, or a span, really.

MARCY:  Yeah, I think there are so many cases where you could argue that a validator is just not going to be up to date with Web components and all kinds of things.

CHRIS:  That's a hard conversation with your client.  You'd probably just --

MARCY:  That is a hard conversation.  Yeah.

CHRIS:  Photoshop a green scare on there and be like, look, we did it.

MARCY:  [Laughter] Yeah.

CHRIS:  Anyway, let's do another one.

DAVE:   Yeah.  We got one from Benjamin Sulm writes in, "With the prevalence of front-end frameworks like AngularJS, there seems to be a rise in logging in via ajax instead of a traditional post back.  I'm all for ajax in almost every case on a Web application, but when it comes to log in, log out, I feel the perceived load time is much better than the traditional post back.  I haven't done any A/B testing with real users yet, but I'd love to hear your thoughts."  Chris?

CHRIS:  That seems weird.  He's talking about a login situation, right?  You have a Web app, and you click a login button.  Perhaps it reveals a user name and password input.  Benjamin's idea that it feels better or faster or nicer for some reason to not use ajax to log in, which seems weird to me.  It seems like it's just a UX thing.  It's like you can make ajax feel however you want it to feel, for the most part, right?

MARCY:  You can.  Yeah.  You have to guide that experience a little more.  

DAVE:   How do you typically approach it because you do Angular work?

MARCY:  Yeah.  Well, the biggest thing is handling the focus so that when you're -- you know, you're not totally refreshing the whole page.  You're just replacing part of it.  Usually in a client rendered application like an Angular app, you're ripping out part of the DOM and putting it back with something else.  So you have to make sure that if the user was focused in that area of the screen, you have to send them back into that new content as it appears.  That's the biggest change is you actually have to manage the user's focus.

CHRIS:  Yeah, I can imagine that because you don't get a fresh page load to move them.

MARCY:  That's probably the most glaring thing that people would forget.  I mean, that has a pretty big impact.

CHRIS:  The state of the page changes when you log me in, like you're taken to a new page.  So if you're taken to a new page after logging in, where is that focus?  Is it back at the beginning of the document, or does it plop them somewhere kind of awkwardly on the page?  I would think it's a manageable situation.  There are some advantages to an ajax load, and it's always -- it can be a faster, smoother experience not needing to reload the entire page, but I have noticed that a lot of Web applications, even if it's an Ember app or the entire thing is generally ajax, sometimes just the login will be post back.

MARCY:  Yeah, so one thing I should mention though is, if you're using ajax, obviously you're requiring JavaScript.  And so there are a lot of people who feel that your app should be usable if you don't have JavaScript.  I being in the Angular Material world, and any modern Web application requires JavaScript, so I am of the opinion that it is okay to require JavaScript, but you should at least have some sort of a warning message for people who don't have it like, "Hey, JavaScript is required."  

CHRIS:  Right.

MARCY:  I think that that is an okay expectation, but you at least need to warn people if that's the case.

CHRIS:  The way we do it at CodePen is a no script tag that has a styled modal warning that explains that this site requires it and why, has a link to--if it is accidentally off in your browser--how you might enable it, and allows you to have a kind of broken experience if you want.  There's a way to close that dialog and just see what's on the page anyway.

MARCY:  Yep.

CHRIS:  That's kind of cool.  You know, and if you can make your login a progressive enhancement experience, that's wonderful.  You can have a form with an action URL that points to a place that will get somebody logged in.  Certainly login is something that you could build progressive enhancively.

    The reason we don't use ajax login at CodePen is because we can't make the homepage HTTPS because people can build things on CodePen that link to resources that aren't in HTTPS, and then it's weirdly not secure anywhere.  It can throw unsecured warnings, so it's like we just have a unique HTTPS for sure page.  That's the login page.

MARCY:  That makes sense.  

CHRIS:  I think there are a lot of sites that, for whatever reason, can't be HTTPS throughout, and thus can't have ajax login because you can't send an HTTPS ajax response from an HTTP page.  It won't let you do that.  The parent page has to be HTTPS in order to make that secure.  If you can't go HTTPS throughout, you're looking at having a dedicated page for your login anyway.

DAVE:   Yeah.  Hmm.  I wonder.  I guess, from a screen reader perspective like the modal versus ajax thing, like if you login, and it's going to start at the top of the page again, right, when it starts reading.  Is that more frustrating than--?

MARCY:  If you refresh the page, or if you lose the -- like if you rip out part of the DOM that their focus is on, it's called freak-out mode, and that's --

CHRIS:  Oh, so never do that.

MARCY:  -- that's when your --

CHRIS:  Or move their focus before you rip it out.

MARCY:  Yeah, you have to basically -- yeah, you have to manage that focus so that you send it back to relevant content because if you lose the focus, that's just a really bad experience, and it can be unexpected.  You don't know where you're going.  The one thing about the traditional page refresh login is that it's expected that the page is going to refresh, and you're going to start from the top again.  That's why skip links are so useful is because then you can help people skip back to actual content.  I tend to think that the asynchronous ajax experience can be better because you're a little easier to actually -- I don't know.  You have to think about managing their focus across the whole app, so once you're thinking about that, I think you could make a pretty cool experience.

CHRIS:  Yeah.  I generally agree that it's a nice experience if you can pull it off because you don't have to leave the page that you're on.

MARCY:  Yeah.

CHRIS:  Which, that's the big deal.

DAVE:   Yeah.  And if you're just doing simple auth, like log in, log out, then ajax is sweet.  But if you're, like--I don't know--tearing down the whole page and rebuilding it, maybe it's a little bit -- I don't know.

CHRIS:  It's too much code for too little.

DAVE:   Yeah, I don't know.  Maybe just a simple post is better.  I don't know. 

MARCY:  Yeah.  Definitely, I think there are pros and cons of both.  If you're managing a single page app, and you're getting to the point where you're managing focus for everything, there are probably other things you have to worry about like memory leaks and performance because you're never refreshing that page, and so, for a single page app, there are a lot of things that you have to consider.

DAVE:   In your line of work, Marcy, is managing focus just--I don't know--is that the IEA of your life?  I guess you also have IEA, but is that just your, like, ugh, I'm going to have to do this, or have you kind of picked up how to do it?

MARCY:  I don't think it's too bad.  We're kind of -- because we're building individual components, we always make sure that within that component, says it's a dialog or something, the button that launches the dialog has to send focus to the dialog and back.  There are kind of those micro optimizations to individual widgets, but in a whole app, you definitely have to have a strategy for handling that.  

    An app that I did do that on is a whiskey app called Distiller.  

CHRIS:  Hmm.

MARCY:  That's Drink Distiller.  It's a whisky recommendations app.  And, of course, any project I get on, I have to put my accessibility stamp on it, and so that is a SpineJS.  It's kind of a mix of a Rails app and a Spine app, and so they were definitely ripping out DOM views and then having to send.  Like, I had to actually go in there and add a focus manager.  My awesome teammate Barton and I worked on that together, and it made it a lot better so that when Handlebars would do its templating magic, we could make people not want to break their keyboards by making the experience better.

CHRIS:  That's awesome.  Is there -- do you do like a find in project for anywhere that calls, like, that remove or something, and that's -- or do you watch for particular events?

MARCY:  I think there was a focus event always running on the body, and if there was -- it was kind of a network of things that all had to work together.  But the main idea was that the body was always watching for a focus.  Then -- yeah, it's been a while since I've worked on that.  I know that it had --

CHRIS:  No, no, it's just such a clever idea.

MARCY:  It was interesting.

CHRIS:  I like that you -- yeah, it really is.

MARCY:  Like it had -- you know, there's one event that's kind of delegating the whole page, and it's always looking for things to pick up on.  Then when it found the right scenario, it would, like -- we had a couple ways of specifying.  It was like if there was an identical element or an identical node that reappeared on the page, it would automatically send you to the identical node.  Or we made it you could add a data attribute on an element to say, hey, when this view gets replaced, here's the ID of the element you're looking for to send focus to.

CHRIS:  Whoa!  Clever! 

MARCY:  Yeah, so it was kind of like it could work in multiple ways.

CHRIS:  Yeah.  Data go to.  

MARCY:  Yeah.  And whisky, I mean, it's a pretty cool project.  [Laughter]

CHRIS:  Yeah.

DAVE:   Yeah.

CHRIS:  You can be in any shape.  In fact, you know, let's say you broke your hand snowboarding.  You've got to tab around websites, but you're certainly drinking.

MARCY:  Yeah, exactly.

DAVE:   Yeah.  

MARCY:  Drunk user testing.

DAVE:   [Laughter] Yeah, I'm not sure a mouse is actually the right browsing implement when you're not sober - something to think about.

MARCY:  Yeah.  Obviously, you know, an alcohol related project is not for everybody.  Not everybody participates in that kind of thing.  But for me, actually, any project where I can go and make it more accessible, I feel is cool.  And so it made it interesting to me.  I personally like whisky a lot though.  [Laughter]

DAVE:   Good.  Good.

CHRIS:  Speaking of learning things, you should go to --

DAVE:   Segue.  

CHRIS:  -- L-y-n-d-a.

MARCY:  [Laughter]

DAVE:   L-y-n-d-a dot com.

CHRIS:  Go to /shoptalk.  It looks like it'll redirect you to /plans then, but it kind of gives you access to a free preview account that gives you access to signing up for Lynda.com free for a week, so you can check out their entire library of courses, of which there are many, many thousand and a new one being posted every day, which is kind of insane.  I have a course on there that's a couple years old, but I knew when I was making it I was making a course that would live through time.  The idea was, you know, kind of taking a design all the way from a blank white canvas all the way through a completed WordPress theme, so that's my course.  But there are lots of other courses on WordPress in there as well, as well as all kinds of things on audio and music editing and business and 3-D animation, design, and all this Web development stuff that we talk about.  All that is available on Lynda.com with a subscription that you can check out.  Get a week for free at Lynda.com/shoptalk.

DAVE:   All right.  Thank you, Lynda.  We really appreciate it.  We've got another question from Andrew Frank.  "I spend most of my day, workday, as a visual and interaction designer at a small agency in Cleveland.  But I am lucky enough to do a bit of HTML, CSS and, very recently, SAS, SCSS for the Wyn.  I bug the dev team all the time with new things I learn from Shop Talk and other various Internets.  I'm kind of a fact finder for them.  Anyways, my question is concerning ARIA attributes placed on icon fonts and the accessibility issues that can arise if you use the wrong one."  Uh-oh.  "For the past year or so, at an agency I work at, we've been using icon fonts and slapping the ARIA hidden equals true on all of them.  I recently learned of ARIA label and ARIA labeled by.  Dave, since you're the accessibility master," that is not a fact, "what is the best and/or proper way to use these different attributes?"

CHRIS:  That's probably good.

DAVE:   Yeah, I'm going to defer to Marcy.

[Laughter]

DAVE:   Okay.  So there's ARIA hidden, which --

MARCY:  Yes.

DAVE:   -- you can hide from screen readers and assistive technology, but how do ARIA label and ARIA labeled by kind of work?

MARCY:    ARIA label, you provide a label, a string directly on an element, so it basically replaces a label element.  It will add an accessible name to a form control or something.  ARIA labeled by is a similar attribute, except it points to the ID of an element that is the label, so you could use that with something other than an actual label tag because a label tag and an input tag are BFS.  But sometimes you're working on, like, say it's material design input, which is a custom element that won't actually pair with a label element.  

I think ours -- I'll kind of like glaze over the details, but we actually nest native elements inside of that.  But there are a bunch of scenarios of, you know, maybe an ARIA attribute works for you.  You'll want to check support for ARIA label, for example, and make sure that it will work for the browsers that your users need.  Maybe you're working on a government site or something that actually you do need to support older browsers.  It's worth looking up support for those attributes.  But I use ARIA label quite a bit just to directly label a form, like a custom input.

CHRIS:  Nice.  

DAVE:   I'm curious.  Do you use ARIA labeled by, because that seems like one of those esoteric --

MARCY:  Sometimes --

DAVE:   -- one guy, one guy did it some certain way and it made it into the spec?

MARCY:  Yeah.  Sometimes --

DAVE:   That's how it feels to me.

MARCY:  There's ARIA described by too.

DAVE:   Okay.

MARCY:  I think there's a nuance.  I'd have to go review it.  Any time I use these things, I'm usually looking at the spec to make sure I'm using them correctly because I have not used them correctly before, and it does cause more problems if you -- like once you start adding these attributes, it can cause harm if they're not used correctly.  But for, like, ARIA described by or ARIA labeled by, you can actually pair, like, say you have an accordion, and it's controlled by some button or a tab.  Maybe the tab and then the tab content are separate things and you need to actually, you know, create a relationship between the two.  You can do that with ARIA.  

    But getting back to the -- I guess the original question was less about forms and more about icons.  It depends on your individual markup, but I have done the iTag that, you know, that will get replaced with an icon.  I have done it where I'll put ARIA hidden equals true on that so long as there is other text.  Say it's the icon and a word next to each other.  

CHRIS:  Right.

MARCY:  I would hide the icon because it's presentation only.  

CHRIS:  And reveal the other thing.

MARCY:  Yeah, well, and it's also -- we have a comment here in the chat that the iTag is not meant for icons, so semantically that's not what that element is for.

CHRIS:  Yeah, I'd go with the span, probably, in general.

MARCY:  Yeah, the span, the inline element is probably the best for that.

CHRIS:  Think of how many ways there are to get -- let me lay out a scenario.  I think there are so many ways to get icon fonts wrong here.  First of all, you need some kind of element to work with at all, right?  Let's pick a span because there are less things going wrong there.  Then you're applying an at font face font to this element because ideally you want to use a character in that font.  You could put that character right in the span.  But the problem with that is that it'll get read, so whatever you map it to, an A, a period, or whatever.  

Some people are like, okay, well, we can solve that by putting it in the private user area or whatever.  It turns out that's not foolproof, so you can't really do that.  Then, okay, well, we'll put it in private use area, but we'll apply it to that span with a pseudo element instead.  That can solve some of the problems, but even pseudo elements get read and, I think, Safari and VoiceOver mode on OS X, so that doesn't really work.  The way that you can really get it to not read anything at all is to put ARIA hidden true on it, so that's what we've been talking about here.

But then nothing gets read at all, right?  That would be an unacceptable experience.  Let's say it's the little gear icon that opens up the settings on CodePen for a thing.  There's no word that visually accompanies that.  It's just there needs to be another span next to it probably that's visually hidden, but not hidden from screen readers that says, like, settings or something.  So now you're working with two different spans, hiding ones in different ways and scenarios, and you have to make sure you do all that just right to make sure it's okay, and kind of test that the font was loaded okay, that it came down the wire okay and some things being shown.

DAVE:   And it supports by the fonts.  And it's not stupid….

CHRIS:  I don't know.  I didn't mean to turn this into a tirade, but it ends up being one in my mind of like how many ways you can screw up icon font, whereas you could have just used an inline SVG, used the accessibility attributes built into SVG to describe what that thing is, and have kind of been good to go.

DAVE:   I think IE8, those --  

CHRIS:  That's troublesome still?

DAVE:   That's, for me --

MARCY:  It's still a thing.  

DAVE:   To the tune of like, you know, 80,000 hits a month or something.  

MARCY:  Wow!

CHRIS:  It's a site-by-site choice there still.

DAVE:   Yeah. 

CHRIS:  You could, if your JavaScript … is acceptable, there's ways to handle it there too.  But certainly icon fonts do work in IE8.

DAVE:   Yeah.

CHRIS:  So I'm sure that's why a lot of sites are still using it.

MARCY:  Yeah.  Something I just read yesterday that I thought was interesting is a draft for the CSS Alt property.  Have you guys heard about that?

DAVE:   Yeah.  Bruce --

CHRIS:  Yeah, so you can label a pseudo element?

MARCY:  Yeah, because if you have a character in your content of a pseudo selector, as you said, in VoiceOver, it will actually read it out loud, and I had noticed that as well.  There's a spec.  You can actually do this in WebKit, apparently, but if you put an Alt property in a pseudo element with content, you can provide either an empty Alt if it's decorative, purely decorative and doesn't have any, you know, and no label would be appropriate.  Otherwise this proposed thing would allow you to essentially label the content in a pseudo element, which is cool.  

DAVE:   Yeah, because the way it kind of -- if you inject content like a snowman, like screen readers will read that before content, right?  They'll, like -- it'll be like link, you know, link, home, snowman.

CHRIS:  Right.

DAVE:   But it would -- you'd want it to just ignore the snowman.  The snowman is just decorative.  

CHRIS:  Now you can do that without having to say ARIA hidden true.  You say Alt.

DAVE:   Alt block.

CHRIS:  Right, and that isn't going to -- I mean, that's a new thing.

DAVE:   Yeah, well, there were some kind of hater articles about it, am I right?  Is that kind of the -- people are back and forth on it?

MARCY:  Yeah, there's definitely some back and forth on topics like that.  But, you know, there are other ideas for CSS, like there was a proposal for -- I don't know if it was even a formal proposal, but Web components.  There was another thing called decorators that is not -- it doesn't have a spec, but it does some crazy magic with your CSS.  That one I definitely, there were some security arguments and things that made that not a good idea.  But the CSS Alt, given that I just learned about it yesterday, I need to go and read what the haters have to say.

DAVE:   Yeah.

MARCY:  It looks like the CSS working group there, somebody emailed protesting against the syntax of that.  Yeah, there's always going to be a hater.  I think it looks pretty awesome, personally.

DAVE:   All right, well, we'll be looking into Alt a little bit more, but yeah.

CHRIS:  Wouldn't the holy anti-article be like if it's in CSS, it's decorative, it's not content, it doesn't need this?

MARCY:  Yeah, but then the content in a pseudo selector is, like, they've already made the decision to have that read aloud in a screen reader, so we need a mechanism like that if that's the case.

CHRIS:  We do.

DAVE:   That's where, like, I could -- like, I could ride the, like, CSS is for presentation, not content, you know, but.

CHRIS:  Well, they shouldn't be read.  Pseudo selectors, it's a bug that they are read, so we're fixing a bug with another attribute.

DAVE:   Yeah.

CHRIS:  I'm not -- this is totally devil's advocate, you know.

DAVE:   No, I just --

MARCY:  It's good to at least consider those things because, you know, like the decorators thing.  Before somebody pointed out that that was a security issue, that sounded like a good idea.  

DAVE:   Yeah.  I mean, yeah.  I just -- if it is presentation, it's -- but then, yeah.  But we have a content attribute, so the CSS is also for content, therefore we should control how it's described. 

CHRIS:  Yeah.

DAVE:   I don't know.  I'm still into the idea of attribute style sheets that Tab Atkins posted about specifically for things like ARIA attributes and stuff like that, ARIA roles.  

CHRIS:  I don't know much about that one.  

DAVE:   It was called A-S -- nope.  

[Laughter]

CHRIS:  Nailed it.

DAVE:   Hold on.  Attribute -- I don't know -- attribute sheets or something.  I don't know.  I'll see if I can dig up an article, but it was just kind of the idea that you could, you know, just like you key value declare things in CSS; you key value declare properties in a style sheet kind of thing so that way you could kind of control your ARIA, like body.open.widget would be -- you know, then you could say ARIA expanded equals true or something like that, rather than having to kind of manage that state in your JavaScript, in your markup.  You could just throw classes in places and start opening and closing things.

CHRIS:  Oh.

DAVE:   So it was an interesting thought.  I don't know why it didn't really go forward, but anyway.

CHRIS:  I have some guesses.

DAVE:   Yeah.  All right.  

CHRIS:  Let's do one more so we can wrap up here.  

DAVE:   Probably the name, the abbreviation didn't --

[Laughter]

CHRIS:  Could be.  Naming things is half the battle.

DAVE:   Attribute style sheets: think about it.

CHRIS:  A-S --

DAVE:   Hey!  This is a PG podcast.  

CHRIS:  I stopped in time.

[Laughter]

DAVE:   All right.  Maybe we should --

CHRIS:  Austin Pray writes in, "What do you guys think about minifying HTML?  I'm a frequent contributor to a couple yeoman build proc generator projects.  This means I'm on the frontlines when it comes to the build process TheoryCrafting with Gulp and such.  One thing that comes up from time-to-time is whether people should minify their HTML.  People usually say Google recommends you do it, so do it.  And YSlow recommends you do it, so do it.  However, they do not consider that minifying HMTL is not side effect free.  HTML minifiers can mess with your white space and sometimes cause bugs to appear in the layout if you use, well, for example, on display, inline elements."  

I guess we can get all into that, but I think most of y'all HTML wranglers out there are aware of this is that inline elements, if they have space between them, any white space at all between two inline elements in HTML, that it will render a space, display inline block either or inline table or inline flex.  Any inline elements at all will render a space between them.  And if an HTML minifier runs and strips all white space between tags, that's going to be a layout difference.  It is not like minifying CSS, which has no repercussions whatsoever on the CSS output.  Minifying HMTL can, and that's just one of the ways.  Imagine the code in pre-tags that you have layout stuff in there.

DAVE:   Yeah….

CHRIS:  So you should say, okay, well, HTML minifier, I didn't even finish the question before going off on my own tangent here, but I'm just doing it.  Imagine -- so you say, okay, well, if we see it that it's a span, of if we can tell that it's an inline style element, then we won't strip the white space around it.  But that doesn't quite work because CSS is involved, and CSS can make elements in that block.  You can have a series of divs that are flex boxy or display inline block.

DAVE:   Blank space pre or something.

CHRIS:  And you wouldn't know that.  So an HTML minifier can't read your CSS tour.  Even if it could, that would be mega-complicated and probably too much.  Anyway, Austin Pray goes on to say, "But it can chop the file size of your HTML by 30% or more," and he says it's a bit misleading because, of course, minification is only a part of the deal there.  I think the bigger gains from G zipping anyway, but people always minify and G zip.  That's been a thing forever, so why don't we do that with HTML.  I think the idea is just because.  Because it's so problematic, people generally don't do it.  I stay away from it.  That's for sure, but anyway.

MARCY:  Yeah, it seems kind of unnecessary to me, but I could see if you're on a giant website where there's like a ton of markup being written out that you don't have control over.  Like, I have seen on Target.com, for example, just like an endless stream of markup, and it never seems to end.  That definitely would add to file size.  

CHRIS:  Mm-hmm.

MARCY:  For big, giant sites like that, maybe.  But, I think, for your -- you know, any site where you can control other things first like minify your CSS, minify your JavaScript, cut down on HTTP requests, all that kind of thing, I think there's probably a lot more that you could do before having to try minifying your HTML.

CHRIS:  Yeah, that's the classic thing, right?  There's probably 15 things that your screwing up on.

MARCY:  Giant images.

CHRIS:  Yeah.  

DAVE:   Yeah, I wonder why.  It's always like, you could save 532 bytes if you minified this.  It's like, Google page speed, I am not concerned about that.

MARCY:  Yeah.

DAVE:   You just need to chill out.  

MARCY:  I think there are other things you could do first.  

DAVE:   Yeah.  But they make it such a big number.

CHRIS:  It's come up on CodePen a couple of times because you can choose.  If you're writing in HAML, Jade, Slim or whatever, an HMTL preprocessor, there are settings that you can tell it to do.  So, for the most part, we try to output it in the pretty format, but sometimes you want control over that because you really want to do the technique with inline box where there is no space between them.  I think HAML has a way to do it.  There's a little flag you put at the end of a line, and it will put the next tag below it right next to it with no space in it, but not all languages are -- I don't know.

DAVE:   Preprocessor.

CHRIS:  Have that, you know.

DAVE:   Yeah.

CHRIS:  Jade, there's a comment you can put at the top of the file that says, like, //jadecompressed, and it will compress everything.  

MARCY:  Oh, interesting.

DAVE:   I could see with, like, the critical path rendering stuff, you might want minification.  Just in theory, you're getting more bytes into that first payload.

CHRIS:  Oh, that's true.  You get more content per packet.

DAVE:   Yeah, so maybe it renders faster.  But again, we're talking like, well, I mean, I guess on a phone it could be a matter of a half second if it has to go….

CHRIS:  I've never met somebody that said, "You know what's the most important thing you can do on your website?"

DAVE:   [Laughter]

CHRIS:  "Minify the HTML.  That's it."

DAVE:   Yeah.

CHRIS:  "That's the killer."

DAVE:   We should see if we could get a Paul Irish sound byte or something, just Paul saying --

CHRIS:  No.

DAVE:   "Minifying HMTL is the most important thing, in the whole world, to your website."

CHRIS:  Oh, we should wrap it up.

DAVE:   All right, yeah, let's.  Marcy, thank you so much for coming on the show.  Before we leave, how can people follow you, give you money, and then what's one big thing you'd like to plug before you go?

MARCY:  Sure.  Well, I'm Marcy Sutton on Twitter and GitHub.  I would rather have people go and write accessible websites than give me money.  

CHRIS:  Wow!

MARCY:  Yeah.  I think we can't continue to act like it's not important.  I've been told accessibility has been solved before, and that's obviously not true.  

CHRIS:  Nice.

MARCY:  Because we keep --

DAVE:   Thank goodness.

MARCY:  Yeah.  Thanks, guys.  You don't want to accept my talk proposal because accessibility has been solved.  

CHRIS:  Oh!

MARCY:  Yeah.  

CHRIS:  Oh, brother!

MARCY:  That was valuable, valuable feedback.  I think, just talk to your coworkers.  If you notice people not thinking about accessibility at all, just stand up for your friends with disabilities and say, hey, this is important.  You know, we're leaving people out.  It's a spectrum of, like, you're not going to fix accessibility immediately for everybody overnight.  It takes time.  But if you're at least thinking about it, you can get the low hanging fruit things first and then gradually add in more accessibility support as you work on stories.  Just integrate it into your process.  

DAVE:   Cool.  Awesome.  Yeah.  

[Applause]

DAVE:   You get the Shop Talk cheer, Shop Talk ovation.  

CHRIS:  We were going to have a live studio audience today, and it didn't work out.

DAVE:   It didn't work.

MARCY:  Oh!

DAVE:   Yeah.  All right, well, thank you so much, and we really appreciate it.  Yeah, it's always a pleasure to have somebody who can deep dive about accessibility issues, so thank you for your expertise there.  

MARCY:  Thanks for having me.

DAVE:   Great.  And, everybody, thank you for listening live, tuning in live, struggling through the live show.  And thank you for downloading their in your podcatcher of choice.  Be sure to vote us up, star, favorite, do all that stuff.

CHRIS:  You can throw us a four-star for that one.  

DAVE:   Yeah, just a -- yeah.  

[Laughter]

DAVE:   That one -- Dave's Wi-Fi is about a two-star, but really appreciate that, and any votes you guys give us, or whatever, that helps word get out about the Shop Talk Show.  We really appreciate that.  And, Chris, do you got anything else you'd like --

CHRIS:  ShopTalkShow.com.