[Intro Music] [Title: technica11y]
>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. On this webisode we have web accessibility specialist, Eric Eggert.
>> MICHAEL BECK: It would really help if I unmuted myself. (Chuckles).
>> MICHAEL BECK: All right, ladies and gentlemen and all variations thereupon, welcome to this October 2019 edition of technica11y! It is fantastic to have you with us today as we kick off our second season. Yes, it's been a full calendar year since our first webisode, so a hale and hearty thank you to those who have been with us every month since then and I do see some of you in the participant window and an enthusiastic and warm welcome to those of you who are joining us for the first time! We hope you'll continue to join us in the future as we continue to present these deep dives into the, well, technical aspects of making the web accessible.
Today's presenter is Eric Eggert. Welcome, Eric.
>> ERIC EGGERT: Hello. I'm unmuted! (Chuckles).
>> MICHAEL BECK: Eric, as I said, a web accessibility specialist. He is with Knowbility and a member of the W3C's Web Accessibility Initiative and he'll be talking today about the pitfalls one can come across while using the Accessible Rich Internet Application attributes in one of the most cleverly named presentations I've seen in a long time "ARIA Serious?".
I know I hear a lot of about the misuse of ARIA on a daily basis at Tenon and how it's meant to supplement HTML but, unfortunately, too many developers tend to use it instead of proper semantic HTML but I'll let Eric cover that, so take it away, Eric!
>> ERIC EGGERT: Thank you for the invitation. Yeah, this is my talk, "ARIA Serious?". I'm a web developer and teacher who works with Knowbility, which is an Austin nonprofit, on improving the web for people with disabilities. And 50% of my time I work with Knowbility goes to W3C in a fellowship model so I can do things like working on tutorials and other stuff.
So that's really nice from Knowbility, so that's why I want to shoutout and say, "Thank you," for that.
And yeah, this is a presentation that I like to give because it has two components in it. It's first an overview and then we look at like practical examples, real life examples. But that means because those are real life examples, I have to put a warning up first.
This presentation contains ARIA examples that are preventing Websites and applications from being accessible. So, please, don't just copy and paste the code that is in this presentation because, you know, it will break stuff. That's the whole point.
And yeah, I will do my best to describe the code examples that I have in there and read them aloud. So, if there is something that I need to repeat or specify, please let me know. So what is WAI-ARIA, really? So, Michael already said, it's the Accessible Rich Internet Applications. That's the ARIA part. And the WAI part is Web Accessibility Initiative. So, there had been a name clash so we had to prefix it, so it was one of those. You can basically ignore the WAI part and be good with it.
But the core with ARIA is the attempt to take accessibility APIs that are present on the desktop, in this case a Windows XP type of desktop environment and map that to the web.
So, making it possible that web applications can basically use the same APIs as like native applications on those platforms.
So, it's really important to know that this is about Internet applications, the emphasis is on that. And we have to keep that in the back of our mind when we use it, especially on "non-applicationy" websites.
Some might think ARIA is just, "You put it on and it works!" But it's neither witchcraft nor sorcery; it just doesn't work like that. You really have to know what you're doing. There's no `ARIA-make-accessible = true` that just makes your website accessible, like, in one fell swoop. It's how ARIA interacts with the rest of your content and we have to understand ARIA and the principles, the underlying principles, fully, and then deploy it where we need it.
There are five rules of ARIA. From the Using ARIA document.
And I think going through them one by one really gives us a good impression on what that is and I have a couple of examples and demos in there, so we know how to use ARIA.
The first rule is, "If you can use a native HTML element or attribute with a semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so." That's a very complicated way to say, "If there's an HTML element that does what you want it to do, then use this HTML element."
The second rule of ARIA is, "Do not change native semantics, unless you really have to do."
And that basically means the semantic of HTML elements is already set; a paragraph is a paragraph, a list item is a list item.
We already know that.
So if you don't really have to change that, then don't. And there are only a couple of really good reasons to change the native semantics.
So this is one example here and I've seen such things in real life. It's an `<h1>` with a `role=button` and then it is a heading button. That is what the developer thought they were doing.
But the problem is that, because we have the `role=button`, this is not a heading anymore. So a screen reader user using heading navigation would never find the `<h1>` because it's not a heading anymore.
Once you put a `role` attribute on an element, it takes away the semantics that are already there. And replaces them with the new semantics. So this is now only a button and only semantically. Please don't copy this.
The good example is having `<h1>` and then a `<button>` inside that. And then you have basically both. You have an `<h1>`. And you have a '<button>'. And that works.
And it also has like keyboard navigation stuff built in, which is also important.
If you say, oh, this makes -- nobody would do stuff like this, sometimes you see gems like this from my a colleague Nick Steenhout who found this in an accessibility audit an h2 with a class h3 with a role heading because it already is a role heading but we add role heading just to make sure and then there's ARIA Level 1 so actually this is an h2 that looks like an h3 but for screen reader users it's actually announced as an h1.
Why would one do something like that? I don't know. But people are doing some stuff like this all the time. So in this case there isn't an element that has a role heading and a Level 1 and that's an h1 element so use the h1 element. Really simple rules here for ARIA.
Third rule, already talked about that. All interactive ARIA controls must be usable with the keyboard.
And that's interesting because there are two things in there. So first there's the keyboard. And the other thing is interactive ARIA controls.
So there are two classes of ARIA controls. There's simple controls like buttons and stuff like that. Those are interactives. And then you have like the really complex ARIA widgets like let's say a date picker or a grid navigation or something like that.
And those have different needs for keyboard navigation.
If you create a widget that the user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.
So if everything you can do with the mouse to an interactive element, there must be an equivalent way to do it with the keyboard.
Which makes sense.
And all interactive widgets must be scripted to respond to keyboard keystrokes or keystroke combinations where applicable.
And that's a good example in the ARIA practices guide. And I use it because this is a really simple thing. So if you use role button on a div for example, then the element must be able to receive focus and the user must be able to activate the action associated with the element using both the enter or return key and the space key.
And it also has to work with the space key. If it doesn't work with both, then you're basically violating the expectation of the user for such an element. And now a user expects that the button works with the space bar.
And I have a demo here.
So those are four buttons. And they are labeled first, second, third and fourth.
And they are implemented in different ways. So going back to the HTML, the first one is a real button with the class button and then we got a div then we have the div with tabindex equals 0 and then we have div with tabindex equals 0 and the role button.
And I also have an event list now that listens for the click event and that's on purpose.
So if we go through it using the keyboard navigation, probably I just tell what happens and be the human screen reader.
So you tab through and this, because it's a button, it would announce as first button. This would be great. So now if I press the tab key, because the second button is just a div and although it works like, you know, with the mouse as you would expect, but because this is only a div without anything else, it can't actually be focused. So it is automatically skipped.
So I go to third. And this is only readable because it has a tabindex 0.
So from here to -- from first to second we have basically given up all of the semantics. It would not announce as button because it doesn't know that it's a button. And the third would just announce as third group or other screen readers would be different. But it would not be announced as button. It would just -- because that information is not given anywhere. So we can use role button and then when we tab here, it would be equally announced as the first one.
So the fourth button would be announced as fourth button.
And that's great, that's what we want. This announcement. But this gives us still a problem. Because this first one, I can go back and I can -- if I find it again. Oh, live -- live demos. It's exciting. If you press enter, you get the dialogue box. As what you would expect.
And if you press space, the dialogue box is there, as well.
With the third one, I can press enter and space and nothing happens and the same is for the fourth one. Because we only have put on the role buttons and tabindex 0, the browser knows it's button. But there is actually in the background of the browser they -- on real buttons and real links, they interpret the event listener -- the click event as keydown events and basically make this transparent so you always get the same interaction when you're using a button.
And this is not there if you're just repurposing div. So the long story short really is use a real button if you want button functionality because otherwise you have to do all that work for yourself. You have to put in all of the event listeners for yourself. You have to make sure that it works the right way. So for example, on a button, if you click, then you drag away from the button then nothing should happen if you implement it wrongly like in a different way, you might run into problems where this expected feature is not working anymore.
So while a button seems to be a relatively innocent and simple thing to do, it can be actually quite complicated to implement it if you have to do it by hand so let the browsers do the hard work.
Do not use role presentation or ARIA hidden true on a focusable element.
The thing is, role presentation and ARIA hidden true, they remove either the semantics of the element or they remove the element completely. So if I got a button which is inside a role presentation, marked up container or has raw presentation on it, it will not be announced as button, it's undoing the semantics there.
And if you have ARIA hidden true, then this button will just not be there if you're using assistive technology.
On screen you'll see your focus, it's all good. But a screen reader would just not hear anything. It's like there is nothing and they tap to nothing and that's bad. And the fifth one is all interactive elements must have an accessible name.
So if you have a button, it has to have some text on the button. That's useful. If you have a link, if you have a menu item, those are -- you need to have an accessible name because you navigate through it with your screen reader and the screen reader needs to read something. If you don't have an accessible name, there's nothing to read and you know a screen reader user does not know what's happening for example if you use an icon without any alternative text.
There are different ARIA components. So the first thing is roles and we talked about roles a little bit. We know something like div role main can mark up like the main region on the page. It's better to use just the main element because you know it's built in. It's already an element that has those semantics. And those are completely equivalent. So you can just use that.
You can give a form a role search. So you can use it as a search form. There are role tooltips and alerts, those are not landmarks but they are like telling screen reader users -- mainly screen reader users -- what this element does.
And that's probably a good thing to underline here at this point. ARIA is working mostly for screen reader users so if you don't use a screen heard there's nothing that tells you oh this div is a Tooltip or this form is a search form. There's no interface for that.
So a lot of people are trying to augment their web applications and Websites using ARIA. Which is a good thing. But it only works for people who are using assistive technology that actually interprets those ARIA things so if you're using ARIA and the assistive technology doesn't understand it or the user doesn't use it, then the problem is that you don't get any result. ARIA does not help people who are not using ARIA. It seems pretty clear. But yeah, it needs to be underlined here. But there are not only roles in ARIA there are also states and properties.
So properties are basically things where you'll say, oh, this thing -- this element has something that gives it more meaning. So for example, you got an input with an ARIA described by so you're connecting two things. An ARIA described by points at some text that basically is additional description for the input field.
But then there are states. So if you have a button, it can have an ARIA pressed attribute. That can be true or false. So that's the state this button is in.
So you can have an ARIA pressed fails and then a user gets to it and it says this is a button not pressed then the user presses it meaning presses return or space and then your ARIA pressed would be true, in which case it gets read to the user as this button is pressed.
Which can be used for toggles and stuff.
But that's the difference between a property -- sorry for that.
Between a property and a state.
Yeah then there are things like ARIA hidden true which as I said hides stuff from screen readers which can be useful sometimes but more often than not, yeah, you shouldn't use it.
I already talked a little bit about ARIA support. Yeah, when you're using -- there are some that use it the support is relatively good for a lot of those landmarks, regions, roles and states and properties. Usually that's really okay. It also depends -- because this is super complicated, the ARIA support not only depends on the screen reader but also on the browser and on the operating system so you get basically seven layers of fun with ARIA which is great. Heydon Pickering wrote an article called ARIA controls is poop which always amazes me because emojis are great and he went in and looked at the support for ARIA controls. And ARIA controls is a property that you can use for example on a button if that button controls another thing. And then in some screen readers, you could go back to that button. For example you got expand collapse and then you expand it and then when you're inside the expand collapse you're reading the text you say I actually want to close this and go to the next one, you can go with -- with ARIA controls you could go back to that button, close it really easily. That was in 2016. And today Leonie Watson actually tweeted that JAWS which was the only screen reader really supporting ARIA controls has recently reduced support so the user has to enable it, which is a shame. Because it could be a useful thing to do. But it had so many cases that it didn't get broad appeal.
And that can be a problem with a lot of stuff like in the details of the weeds of ARIA. This is the whole organizational tree of ARIA. And you can see -- well, maybe you can see. But I described it, too. It's basically like a big net of different boxes with different roles and attributes and they are pointing at each other because they are dependent on each other and it's like crossing and really confusing and complicated because ARIA is really complicated. That's full stop. And that makes it very complicated for web developers, as well.
And this is where it goes into the fun part where I tell you stories about really bad code that I've seen.
So this is one I've seen a link with the ID airline logo and the ARIA -- the class logo and ARIA label airline name and then a non-breaking space in between. So that means a screen reader user would be totally fine with this. The screen reader would tab to it and it would read the airline name. But for an input user under different circumstances, the ARIA label wouldn't be supported. So they couldn't click on the home logo. That's bad.
And we do have a way to do this, it's using an image with an alternative text. Or you can do an svg with a title that could work. There are a lot of different ways to approach this.
What one could do is basically this, we have a nav with three buttons and like button elements and you have a nav element if that makes sense and then you have ARIA pressed false and an ARIA label Slide 1 if you hide the text anyway you know sometimes it's okay to put it into the ARIA label and do something like I did here. And then, you know, only the one which is active has the ARIA pressed true this is relayed to a screen reader user and they can go to Slide 1 which is unpressed and then Slide 2 which is pressed.
That makes sense. But it goes even better if you put in an alternative text and an image with the alternative text if you're using a graphic for those 1, 2, 3 buttons.
Another thing I've seen where a developer -- and I know that because I'm a developer by heart we want to be very, very clever. You know, if someone looks at our code, we want them to go like, oh, that's clever. That's what happened here. And this is from a sortable table. And basically it's a th with the content name and it has a tabindex equals 0 and role button and ARIA label sort column.
Now, I know what the developer is thinking, oh a user has to tab to this table header in order to sort the column and then the screen reader needs to know that this is a column they can sort so I put the ARIA label on it and it needs to be a button so I put a button on it. But what that does in combination is this is not a table heading anymore, a table header anymore. So this is not just a -- now just a button and it has no connection to the other table data elements in that column.
So it basically broke the accessibility completely and if the role button wasn't there everything in that label would be labeled sort column and as most columns would be probably columns to sort, that means everything would be labeled with sort column which makes no sense. Name is much better as a label there.
So actually this doesn't happen. This is a tweet by Paul J. Adam where he basically had a similar thing happening. So it's a button with the type button and the role button ARIA required false tabindex equals 0 and then just a 2. And he asks what the heck #facepalm #A11y. Which is a fair reaction I think. So try to unpack that. Going from -- back to false. So 2 is not a really good accessible name. That should change. But it also depends on the context. But then you've got tabindex 0. A button is already reachable by keyboard. You don't need a tabindex 0. So just remove it.
Especially if it's false anyway. Because buttons by default are not required. So you can get rid of this. Then it has a role button, which a button already has. So get rid of that. And then you basically have a button type button, which is useful if this button is used inside of a form. Because inside of a form a button by default submits that form and you don't want that for all of your buttons so you can use type button. But outside of a form, you don't need that.
Another thing that I've often seen is this pattern, it's a span. And it's for an icon. So there's an icon using CSS background or icon fonts, something like that. Then it's span ARIA equals true role image class icon. So you don't need to put a role image on something that you immediately hide from screen reader users. The role image would make this announce as an image. Then you use ARIA hidden true to say oh please don't announce this image. That makes little sense. So don't do something like that. If you're thinking about hidden true you can just in this case probably just remove the role image and the ARIA hidden true and then you're good. Depending on your technique to put that icon in. Icon fonts can be tricky.
A really bad thing I stumbled on was this one. And this is from a big framework that used to have dialogue component. And when the dialogue was up, they wanted to prevent screen reader users from accessing everything inside of the bottom of the page because it's a dialogue people should interact with that and they put ARIA hidden equals true on the body. Which seemed like a good idea at the time. But it really is not. Because that hides everything inside of the body. And as your dialogue is also inside of the body, that would also be hidden. You can't selectively unhide stuff inside of an ARIA hidden field. That's just not how this works. So they basically hid everything from screen reader users. It's not for people who actually needed to use that slide or those slides. But yeah, it's like a big misunderstanding. And so it's really important to keep that in mind. If you put ARIA hidden true on a container, everything inside is just gone and dusted.
So sixth example. And that's one I've found basically it's -- it was a spread in a textbook kind of application. And you had a lot of these links that opened stuff in your windows and had a title click here to view the video on tabindex minus 1 because they put the tabindex of the -- or the taborder manually on stuff, which yeah you can do that. But it's work. Avoid work, if possible.
Then you get a role button. And ARIA label external link.
So -- and there was nothing inside of that link.
So what they didn't think about was that ARIA label is overwriting the text of that link. So in the naming algorithm, it would have been okay to have the title and that would be read like click here to view the video. But using ARIA label overwrote that. So you had basically like ten external links on every page. And you didn't know which video is that and where does it link to.
Also something I've seen using an ARIA live region on a carousel. That's always a lot of fun. Just screen readers constantly getting disrupted because of the content changes. It makes it impossible to use. A lot of fun.
And a little bit of like HTML curiosity. If you're using label for ID and you have an input with the same ID but it's in a different case, upper case, lower case, those attributes are actually case sensitive. So this would break your stuff. So if you're using ARIA label by or something, upper case and lower case, they matter for some obscure reasons. But they do. So just keeping that in mind.
There are two really good resources to read up on that whole thing, how to implement stuff properly. There is the authoring practices guide WAI-ARIA practices guide and on the left in the navigation you basically get grids. You get model dialogues, links, list box. The whole thing. And it will also tell you how you have to implement keyboard navigation on those more complex -- on those more complex widgets. Because that can be very intricate. You know, what happens when you press the right arrow in a calendar grid when you are at the end of the week, where do you go from there? That's identified.
And then there's the using ARIA resource that is written by Steve Faulkner and David McDonald. The editors make a great job to basically lay out those rules, make sure that you can use ARIA really well with HTML and by the way, the team doing the authoring practices, also great, great people. Zoe and John and Gima are great people all around.
Conclusion for this whole thing, use landmarks. Use states and properties. If you can. They make sense to you.
If you're using widget roles like the more complicated things that are in the ARIA Authoring Practices, just keep in mind that there's a lot of keyboard work you have to do. A lot of things that depend on each other. It's quite complicated. And to read up. And then also test it with browsers and screen readers and make sure that it actually works. Because sometimes, you know, there is like a small thing in there that doesn't work. And then, yeah, it's -- it's not fun if you put a lot of time into it and then you see that something is not supported.
One quick shoutout.
There is a workshop I will do in Berlin in November. It's just (inaudible) and you can join with Accessibility Club. I linked that with my slides, as well. And I will talk more about funny things that other people do wrong so I don't have to talk about things I do wrong.
And that's it. I'm Eric. And my Website is yatil.net and I'm @yatil everywhere else. And I'm open for questions.
>> MICHAEL BECK: All right. Yeah, if you have any questions, go ahead and throw those up in the chat or in the Q&A, if you're so inclined.
Actually we do have somebody have -- somebody had a hand open up but they just put it up. Oh there we go, attendees. Who has their hand up? Stuart Nelson. If you have a question there, Stuart, go ahead and throw it in the chat or in the Q&A -- there we go. Hello, Stuart. I think he's writing something.
While he's writing that, I actually have a little curious question for you. What's the yatil? (Chuckles).
>> ERIC EGGERT: People are always asking that and it's -- basically when I've been young, I had French class. And Yatil with three dashes y dash a dash t dash il, that basically means what is.
>> MICHAEL BECK: Ah . . .
>> ERIC EGGERT: And I found it funny that it has three dashes. And so I just took it on as my name. And when I stopped taking French classes, my French teacher said to me, this is a great day for the French language. So you know this is basically my French language. (Chuckles).
>> ERIC EGGERT: Relationship.
>> MICHAEL BECK: Fair enough. All right. Stuart asks with ARIA-required attributes, will the HTML required attribute on its own be sufficient?
>> ERIC EGGERT: Short answer yes. So the -- basically the HTML required attribute does everything the ARIA required attribute does but it also does something more. It gives you automatic validation of your form. And that is useful in certain use cases. So it can -- it has -- it works a little bit differently. But if you have a required on your HTML element, it should be okay.
>> MICHAEL BECK: And he has a follow-up question do you have a favorite pattern for ensuring that form inline error messages are accessible?
>> ERIC EGGERT: It's a little bit hard. Because it always depends on the form. Sometimes inline error messages don't make a lot of sense like it makes more sense to like throw the user back and say, oh, there are several things. But sometimes they make sense.
I actually wrote or edited a tutorial on W3C.org. That has several things, W3C.org/tutorials. I would need to be able to spell that. (Chuckles).
>> ERIC EGGERT: And there is a forms one. That has error validating input on the left. And that has several different things.
And usually, you know, I usually use the standard HTML input fields. And then make sure that I use ARIA described by with the arrows.
>> MICHAEL BECK: Okay. Let's see.
John asks, can you speak about if there is a need for elements to have both the same ID and name attributes being the same?
>> ERIC EGGERT: I don't think there's a need for that. It used to be that I think Internet Explorer 6 or 7 or so did not support jumping two names -- jumping two IDs. So you would need to also give them the name. But I don't think that modern browsers are doing that.
>> MICHAEL BECK: Would you recommend role equals text to help VoiceOver better output text that has multiple spans?
>> ERIC EGGERT: So two answers. (Chuckles).
>> ERIC EGGERT: I think it can help a lot to do that but on the other hand I don't feel that this should be on developers. I think VoiceOver or any screen reader needs to do a better job to do this and work with native HTML. And role text is a non-standard attribute so I'm varied of it. If you have a certain use case where it is really distracting then, yes, use it but otherwise I would not usually use it.
>> MICHAEL BECK: Okay. Roger has a question that's not ARIA related but varied form links can be always deemed bad and demand a change, is that true? Do you think?
>> MICHAEL BECK: Okay. Karli asks can you tell me when you should use a widget versus a straight nav element?
>> ERIC EGGERT: Yes, I can. So if you have a web application which means something like Google Docs or something like that then you want to use menu and menu item. If you don't have that, there is little reason to use it. Better use a navigation and just pointing back, there is a tutorial on that. (Chuckles).
>> ERIC EGGERT: You know, I've written about all of that. So you just --
>> MICHAEL BECK: Perfect. I will definitely have a link for that in the description for the YouTube video.
>> ERIC EGGERT: Yeah so yeah, I think for most people menu and menu item is overkill and it also changes the way you use it with the keyboard so that can throw keyboard users off.
>> MICHAEL BECK: Okay. We have a couple more questions and then we'll wrap up. Richard has a question. He wants to revisit exhibit No. 2.
Would the ideal situation for that one just have the text instead of ARIA labels equals dot dot dot?
>> ERIC EGGERT: Yes.
>> MICHAEL BECK: And that would generally be better for accessibility and SEO do you think?
>> ERIC EGGERT: I don't know a lot about SEO. Because my philosophy is search engines want to present stuff to users so if your code is user friendly it probably would be picked up for -- from search engines, as well. The thing is if it's a button it does not have any like big impact on your SEO I guess. But the thing where having Slide 1, Slide 2 inside of the button really shines is when you have voice input because a voice input user can immediately know what that is. So actually it would be good if the text would actually be visible.
>> MICHAEL BECK: Okay. Is native browser validation accessible enough or do we need to make it accessible by means of ARIA attributes for example only first non-valid entry is highlighted or announced?
>> ERIC EGGERT: I think it works pretty well almost always. If your user presses the submit button and there's an error going through the first instance makes sense, setting that -- or highlighting that input field, yeah, but the user -- the browser should do the heavy lifting for you usually. I'm trying to break that as much as possible. (Chuckles).
>> MICHAEL BECK: Okay. And Stuart has a follow-up question. I know what the real answer is do you have a favorite automated accessibility testing tool? I know what the real answer is but he asked if you have tried AXPro.
>> ERIC EGGERT: I have to say that Tenon is my -- (Chuckles).
>> ERIC EGGERT: No it's -- just kidding it's a great tool I use every tool that's out there on and off but I'm not much of a tool user actually so what I usually do is use bookmarklets that are written for mostly myself or I adapted. And there are a lot of good bookmarklets out there that just reveal stuff to me and then I do the heavy lifting manually that's how I roll because I don't trust no one except for Tenon obviously.
>> MICHAEL BECK: Obviously. (Chuckles).
>> MICHAEL BECK: All righty then. Well thank you very much, Eric. That was wonderful. That was a deep dive. I will say the whatchamacallit the contents fit definitely. So thank you, again, and thank you all so much for being with us today and I hope you'll join us next time when Tenon's own Karl Groves will be presenting on what? Who knows. We all know Karl has a whole lot to talk about just about everything and he hasn't quite decided on the topic yet so it will be a bit of a surprise for us all. So on behalf of Eric and Clare, our captioner from ACS, thank you all for joining us and as always I hoped you learned something today. Have a wonderful day! [Title: technica11y] [Title: Presenter - Eric Eggert @yatil] [Title: Moderator - Michael Beck @stilts121] [Title: Music - bensound.net] [Title: Captions - acscaptions.com]