Transcript from the "Progressive Enhancement Exercise" Lesson
[00:00:00]
>> Marcy Sutton: That's how I could make, like that's the start of how I could create something that's more progressively enhanced. And I've got some examples here, the tab list you could play with, maybe adding more functionality to that. I have this starter here that my feelings will not be hurt if you want to go over here cuz this is what I think more of when I think of progressive enhancement.
[00:00:22] This is a little bit more similar to like the Gatsby thing kind of abstracts it away, which is fine, but this is a cool thing to work on. So I have this little ARIA tab switcher and it works. It's using the pattern similar to what you can find on the ARIA authoring practices guide.
[00:00:41] But there's all these classes in here and let's say ARIA, I've named it to rely on ARIA. So I might go through and change those to be a little bit more generic. And then so how I would change this is to go through here. Remove the things that rely on scripting and probably change the CSS.
[00:01:02] Maybe I'd add no-js class here. And when JavaScript loads I could go, document.body, I don't know, go remove the CSS class somehow. And then that gives you the styling hooks. It's like JavaScript's downloaded, I can go play with the CSS now and enhance this thing. So what I would sort of recommend doing for this is changing the CSS when JavaScript isn't turned on so that it just renders everything.
[00:01:37] Maybe it's just a big long list of stuff. And when you turn JavaScript off, you can still read all the content. Cuz right now if I turned JavaScript off, it's gonna look exactly the same, but I'm not gonna be able to get anything. There are some patterns with playing with label and input elements that you can make kind of a native HTML tab switcher, but it's not super accessible for screen readers.
[00:02:01] So I think it's fine to use JavaScript but we can just layer it on top of the sort of baseline HTML. So there was a question about the logic for using the spread operator with the end client. It's actually a Boolean from the used state, so it's either true or false.
[00:02:22] It's pretty crafty, so the spread operator is actually spreading it onto the element in jsx, which I'm guessing is an object under the hood. That's how you can easily swap out an actual li or a custom one. So interchangeably is that they represent those with JavaScript objects under the hood.
[00:02:44] So if spread its client onto it and use this double &&, it will combine this object with role of tab to the representation of the element if this condition matches. And it just short circuits a longer ternary condition to check that. I did add an alternative here, something that might come in handy later is to just start with the role attribute.
[00:03:13] And then giving it a value no matter what the condition is. So in this case, I'm saying if isClient is true, give it a tablist role, otherwise, give it the list role. And the reason that you could consider doing that is that, I mentioned this earlier, that Safari needs that list role to be bolted on if the list styles are removed in CSS.
[00:03:37] So sometimes you might want to add a default role just so that a screen reader will respect it with that CSS loaded. But this short circuiting is pretty crafty, and it'll keep that role attribute from being added at all unless this condition matches.