 So welcome everybody to my talk about the topic complex and accessible JavaScript widgets with simple HTML. I'm holding this talk, yeah, in the scope of the Global Accessibility Awareness Day and my special thanks go out to the team of Hello Accessibility. So thanks for organizing this event and thanks for having me here. So a big hello from my side to everybody. My name is Josua or Joshua or Joshua. All three forms are acceptable to me. I'm a full stack web developer for roughly 15 years now. And I can say that I have kind of a deep affection for humanity. I see so much potential in every human being and they have to profound belief that technology should always be used to unlock this human potential. And this means that we have to include as many individuals as possible on this path. So as there was already said, I've been an accessibility expert working for my former employee, Access4All for like eight years. They are doing accessibility business for over 20 years now. So they are like the very early ones that are investing energy and efforts in this topic like in the year 2000 already. And I'm the initiator of the Accessibility Developer Guide which is a comprehensive resource about all topics accessibility which we will see today a little bit more. It's tangible, it's technical and still it's easy to understand. And it offers a lot of code examples which you can kind of take as inspiration or maybe even copy and paste into your own project. The whole guide, including the code is written by developers and for developers but not only developers, also like designers, content creators or other stakeholders, but it's mainly a developers resource. It is open source. So when you head over to accessibilitydeveloper.guide.com we are happy to welcome you in our small but like enthusiastic little group of Swiss and international agencies, web agencies developing this guide together. So I started to work for a new employer this year which whose name is actually nothing. It's just kind of funny. It is a peer to peer organized life as a web agency and venture lab located in Bern close to Bern in Switzerland. And our mission is to help designing a future where technology is used as a tool for humanity and not as a weapon. And our current goal is to become the kind of leading accessible first web company in Switzerland. So if you have any interest in us or our services or our products just head over to nothing.ch Our current flagship product is Peerdom which helps us and our clients to transform to peer to peer organizations. So if you have any interest in this we can help and support you to do the transformation in your own organization. Let's start with a simple question of trust. I mean, a climber heavily trusts in the reliability of his rope and carabiner linking you safely to the rock face, right? And in a highly complex and interconnected world we need structures and values on which to build on which we can rely. And the web design is becoming more and more powerful and often there are many ways to reach a goal. So regarding this link, what do you trust more? A link implemented using an anchor tag using an href attribute or a link implemented using a span tag and an on click attribute. I guess all of you agree with me that it will be the anchor tag to trust in, right? But why? Let me tell you a few benefits of using such traditional HTML. First of all, you get a lot of behavior for free. If you just use this anchor tag, the browser will take care of everything that can be done with this link, which is clicking on it, taking you to the address, providing keyboard focusability or other means of interaction. It offers styles for free, like the usual underline that we see. And it even offers different states that you also can target and style yourself like focus, hover, active states, et cetera, et cetera. Traditional HTML has a huge compatibility with like old and new user agents. So we can trust that this traditional anchor tag will be working in a browser 20 years ago and probably also in a browser 20 years from now. Needless to say, it doesn't need any JavaScript and such degrades gracefully even on limited or older machines. You will say now, let me say a few words about this word traditional, right? So technically spoken, a span is also 100% valid HTML. But when I call something traditional, I mean taking an element which has a traditional purpose for which it was designed and which you can use for exactly this purpose, right? Instead of creating your own custom solution. So you will say now, but wait a moment, we can enhance this span, we can make it look and feel and act like a real link, right? So for sure, we can apply custom aesthetics using CSS here or we can add some custom behavior using JavaScript. We can even make it focusable with the keyboard by using the tab index. What few people probably know is that we can even change semantics. We can use the role attribute which will change the semantic of an element. So the current span will now be announced by a screen reader as a link indeed. Still the question is, how will it perform in the real world situation? And I created a little code pen here. Oops, let me make the browser, not full screen anymore. Let's see how these two solutions or even three solutions, the traditional link, the bear span and the optimized span, how they will perform. So I can click on the link and obviously it takes me to the target. I can also click on the span and that's all right. It works too. What about keyboard operability? I can tap to the link. I can activate it using enter. That's nice. I can not focus the span, the bear one. I can indeed focus the optimized one, but when pressing enter, nothing happens. There's more things. I can try to bookmark the element by drag and dropping the traditional link to the bookmark bar. I cannot do the same with any of the spans, not even the focusable one. It's still not drag and dropable. I also have a context sensitive menu for the traditional link, which allows me to open the link in a new tab. This is not available for neither the bear nor the optimized span, right? So as we see, even though we do our best to mimic the style and behavior of a relink, the spans still are not really links. As we have seen, we cannot open any context menu. We can't bookmark the element. We can't even activate it currently using the keyboard. We would use more like JavaScript for that. And possibly there are many other things that we may not be even aware of that they exist that we would have to take into account and creating such a custom solution. So our entering conclusion is traditional HTML beats quirky custom solutions. Nearly all the time, in my opinion, this is fact because as we have seen, there is much functionality that we just get for free, which just works in all kinds of input and output devices. As such, we can say it's very robust and it is performant. We don't have any like JavaScript overhead. You may say now, but why? Why would anybody implement a link using a span tag, right? So I came, there are three reasons that come to my mind. First of those reasons is just pure ignorance or unaware, being unaware of the situation. And trust me, during the last eight years that I've been working as an accessibility consultant, I've encountered innumerable times that even seasoned web experts were implementing things on their websites with just the wrong HTML elements. Just to name a few typical bad use cases here, for example, list of search results and also navigation menus in single page applications. And just to see a current problematic example that I've just stumbled upon a few days ago, it's Apple's product list. So if you open the Apple product list, you see the hand, my pointer, I can click on these elements, but in fact, they are not links. We don't have a context specific menu here. If we inspect the element, we can see in fact, it's just a picture with a lot of divs around it, but no real link to find here. So as you see, even like the experts are doing this kind of stuff. So it's really a problem. So my advice, or even back all out there, everybody of you, please stop doing this. It's wrong, it's ugly, and it just opens a can of worms of problems, right? So please just use real links or buttons depending on your context. Reason number two, some HTML elements cannot be styled as bushed. This was true, especially in earlier days where many HTML elements just offered limited CSS. And still today, some of the elements cannot be styled in most browsers. For example, the select tag. So if you have the situation where you need a styleable kind of select dropdown, you can use those role attributes. You can just use like a generic diff structure and apply a role of list box to the element resembling the select element. And you can apply many role equals option for all those elements resembling the option elements. The third reason that is that in fact, sometimes HTML is just missing the functionality, the feature, the element that you want to implement. So quite a few well-established usage patterns don't have an HTML equivalent up to this day. For example, there is no tab list tag, nothing like that. So if you are in this situation, you really need to kind of tinker your own custom solution. And just to give an example, you can use an unordered list and apply a role of tab list to it. And for all the tab elements, you can apply role equals tab. So we've seen this role attributes quite a few times now already. Where does it come from actually? It comes from the area, the accessible rich internet applications standard, which was released already eight years ago by the World Wide Web Consortium. It offers attributes to enrich traditional HTML with semantics. And that's the important point. It only adds or changes semantics, nothing else. It does not provide any inherent functionality by itself. So for example, to come back to my diff, my role equals listbox diffs, they will indeed be announced by screen readers now as a select element, but you still cannot interact it neither with screen readers, nor with mouse or keyboard or anything like that. This means you need to add all this functionality yourself using JavaScript. For example, you need to manage all the visibility and styles of the elements. You have to provide keyboard focusability. And the general interactivity of your usage pattern. And what is not obvious at first sight, you also need to update the semantics in the background. For example, if you choose an option here, you need to apply the area selected equals true attribute to the selected option. So this becomes quickly pretty complex. And I will demonstrate how complex it is with the example, an official example from the World Wide Web Consortium, the collapsible drop down listbox example. So let's open it in a new tab and open it in code pen so we can play around with it a little bit. And let's just have a general impression first. So I can click on it, I can open and close it, I can select an option. It looks and feels quite like a select tag, right? Let's see whether I can use it with the keyboard so I can focus it, right? Yeah, I can choose an element, I can press enter to close it, that's all fine. Let's have a quick look at the HTML that was used. So we have a button here and we have an unordered list with roll equals listbox and we have quite a few list elements with roll option. This looks fine so far. Let's look at the CSS. It is 150 lines of CSS, which is quite a lot already, I feel just to kind of mimic a basic select tag but it allows us to do what we initially wanted to do. We can style the element as preferred. We can, for example, apply a red color to the items and now we see beautiful, now we have red elements. This would not be possible with a native select element. Cool. Let's have a quick look at the DOM, the document object model when we are interacting with the element. So let's open it here. So you can see it. Let's just interact a little bit with the keyboard. Come on, all right, open it and browse through the elements. And as you can see, there's quite a lot of things going on. We have the CSS classes that are toggled. We have different area elements attributes which are toggled, which are moved around. Even the button's text is changing manually to the currently selected element right here. So quite a lot of things are going on here and not surprisingly or maybe surprisingly, we need a lot of JavaScript for this. It's 900 lines of code actually that we need to make this element mimic a native select element. And if we think back about the anchor tag which also had kind of a lot of hidden features that we were not aware of, it's probably the same with the native select tag that we need to really make it working for everybody. We need to provide a lot of functionality here. All right. So as you see, we need over 1000 lines of code to make this basic, not native, but a mimicking select dropdown possible. And the problem here is the support for area still varies drastically among different browser and screen reader combinations. So the worst case scenario could be that you invest hours, if not days or weeks into creating your perfectly standards-compliant area implementation, but still some of your users might not be able to use it because they use a browser or screen reader combination which is not yet 100% supported. Also keep in mind that area does not have an answer for everything. So area's bouquet kind of is limited. While it offers a standard for like the list box or the tab list, there is no date ticker, for example, and other usage patterns are also missing. So you will quickly reach the point where there is no official recipe for what you want to achieve. And what will you do then, right? So this is, it's obvious that you can't rely exclusively on area, that there must be some other ways of offering accessible interactive usage patterns. And this is the perfect moment to introduce you to the first rule of area use. It's also taken from the World Wide Web Consortium and it states, quote, if you can use a native HTML element or attribute with the semantics and behavior you require, then do so. Do not instead repurpose an element and add an area role, state or property to make it accessible, end quote. So easily spoken, if there is a native HTML element which does what you're trying to achieve, then please just use this element. And as you will see in a minute, there nearly always exists such a native element, even when not obvious at first sight. But before digging into this, let's first take a look at existing implementations of custom dropdown list boxes, starting with one that we probably all know, Google. So let's open Google in a new tab, enter something into the prompt and we see the suggestions below. Now we're gonna inspect those and we can see Google does as expected, it's just an unordered list with a role of list box and below for each option, we have this diff with a role of option, right? So nothing too surprising here. So, but I have to say, although Google uses those role attributes, screen reader accessibility actually is rather mediocre. I've tested it in advance and while it announces itself as a searchable combo box, which is good, it does not announce any availability of options. So we don't really know as a user, are there any options now? How many are they? How do I interact with them? But if for at random or just if you're an experienced user, you're using your up and down keys, the selected option will be announced to you. The second autocomplete that I wanna take a short look at is Amazon. So to make it short here, Amazon does not use any area. They only use diff and spans. So just a very custom generic implementation, which means that also screen reader accessibility is a rather bad, if not existent. So it does not announce itself as something like a dropdown or a select box or whatever. It just announces itself as a bare text search. A new user would never know that this offers some suggestions to them. It also does not announce, obviously, that there are options, right? At least if at random or by accident, you're using your up and down keys, it will announce the selected option, which is rather a coincidence in my opinion. So in tearing conclusion here, both Amazon and Google, they need a custom dropdown. They wanna style it in an appealing way. So something like a select is not an option, right? Both Google, not both, but Google uses area. Amazon does not use area. Both of them probably have lots of JavaScript in the background handling this element. And still accessibility is mediocre to even bad, right? Right? And this is kind of a, this is not very satisfying, right? So my question, couldn't this be done any better somehow? And I wanna remind you now on the first rule of area usage. Isn't there some traditional HTML element available that we can use for this? And in fact, there is. They are called radio buttons. If you know how to do it, radio buttons are 100% customizable. Namely, you can style your label elements as you prefer, and you can visually hide the input elements, keeping them still focusable and interactive for any user agents, right? So obviously no JavaScript is needed here. And as it's a native element, it's 100% accessible on any platform. Let's have a look at an example for this. And now we are coming back to the accessibility developer guide. Let's look at a list box of radio buttons. In our guide, we call it the ADG auto suggest, ADG for accessibility developer guide. And we will take a look at it in a moment, but let me state first, it is using radio buttons as promised, and it offers very good screen reader accessibility. It announces itself appropriately. It announces the availability of options. It announces the currently selected option and the total of options. And rest assured only a tiny bit of JavaScript is needed for that. So the current talk is kind of a small version of a full day or half day workshop that I used to have to hold, where I show in four milestones how to implement exactly such a widget. And the milestones are number one, basic HTML, just implementing the basic HTML structure. Then number two, adding interactivity using JavaScript. Then adding some basic accessibility optimizations, just a few lines of code, and apply visual styles in the end. So it looks fancy or the way we want it. And now let's just look on the fourth, the final version of the widget. I'm opening in the new tab. And as you can see, it doesn't look very fancy, but you get the point. We can open and close it, we can browse with the mouse through the option. We can even enter some text. It will filter the element. We can for sure use it with the keyboard only. Right. And now let me change the view here to debug mode. So we only see the element and not all the GUI around. So if we disable CSS now, you can see that it's actually really only a list of radio buttons. And by using the up and down arrow key, we are toggling through the element. Very, very easy. Let's see what a screen reader does with that. So I'm opening my Windows 10 virtual machine here. I have Firefox started and NVDA. All right, let's activate speech mode. Speech mode beeps. Speech mode talk. I hope that you can hear it. I really hope it. Otherwise you see it in the speech view. Yes, we can hear it. Perfect, cool. That's very good to hear. So I'm gonna tab now into the input field. Programming language edit collapse 21 options in total. Provides auto suggestions. Blank. So it is announced to us the way we hoped. Let's open it using the down key. Blank, expanded. Tells us it's expanded now. Let's browse a little bit using the down key. Action script, Apple script, ASP, basic, C. So this works pretty well. Clojure. Let's enter a filter. So I'm selecting all of the text now. Clojure selected. Deleting it. Blank. All right. And now I'm entering something. J, three of 21 options for J. Provide A, two of 21 options for J. Provides auto suggestions. So it seems to work. Java, JavaScript. Very well. So as we see, going back to the presentation now, a small verdict, the element is very accessible. It only needs 60 lines of CSS and roughly 200 lines of JavaScript, including the filter functionality. But wait, there is more. There is more such unexpected usages of form controls. In our accessibility developer guide, you can learn how to create a date picker with the exact kind of same structure like we have in the autocomplete. You can learn how to create a tab list or a carousel or an accordion or a menu toggler. But just to give, whoops, just to give one more small example, let's look at the tab list. Opening it, new window. Did it work? Yes, here it is. Scrawling to the proof of concept, which is the actual example. Copy and paste it to our screen reader. Navigation to speech mode off. All right. So as you can see visibly, it just looks like a very basic tab list implementation. You can use it with the mouse, with the keyboard. And now I'm activating the speech. Speech mode beeps, speech mode talk. Going to it again. Tablist controls grouping. Show panel rows radio button checked one of three. And I can browse through them using the down or up key. Show panel tool up radio button checked two of three. Show panel sunflower radio. You get the point. So very, very simple. All right, this was quite a lot. Let's take a short moment to recap. Form controls are very powerful. They can much more than just handle basic user input and data. As we have seen, they can handle many simple usage patterns, even complex ones when combined. They are simple and compatible, robust and performant, and they are innately accessible. And as we have seen now, they can be styled as wished. So to come back to my introductory question, what do you trust more? Like when it comes to linking. Is it a traditional A tag with an href attribute? Or is the span with a lot of noise around it? So please remember next time, when you're tempted to glue together some random different span elements with some JavaScript handlers. Thank you a lot for your interest. If you have anything to talk about accessibility, please reach out to yosuaatnothing.ch. We can have a short virtual coffee break together or just go to our services page, nothing.ch slash accessibility. And to those who are interested into learning more about this specific topic, we will have a workshop, a longer workshop on 28th of July. Just go to tiny.cc slash G A A D 21 hyphen workshop. And for those of you who are registering in the next two weeks, we have an early bird offer. You can pay what you want. You can even attend for free if you like. So I'm happy to see you there. Thank you guys. We have a few questions. And the first one is, what is the difference between custom and native widgets and what to consider in terms of accessibility point of view when developing? So what I call native widgets, it's just like the standard controls that you have in your browser. You don't have to implement anything for them, kind of you just have to use standard HTML tags to use them and they will work right out of the box and be accessible, right? And then you can implement your own custom solutions with different approaches. And you have to keep in mind then that you have to provide accessibility yourself. And area jumps into this gap. So it kind of gives you tools to optimize a generic solution. You don't need area for a traditional native widget or tag, right? So it gives you some tools which you need to know how they are supposed to be used. And then you can kind of optimize, you can polish your existing solution into an accessible one. But let me stress this out, in the previous talk was said, you really need to test it using screen readers. If you have someone available and experienced screen reader user like a blind person, please ask them to test it. I've been working in the field for eight years now and I can say I pretty much understand pretty well now how screen readers and other assistive devices work. But as a beginner, please get yourself some help here of real users. Hi, hello. Hello, I hear you. Yeah. Hi, this is Rashmi. Hello. Can I know what is the practice using link as button? Is it good or I have seen on some sites they are using link as button. Exactly, that's a very good question, yeah. In fact, links and buttons, they have different purposes, that both of them can be focused, can be interacted with, they can be clicked. So they are kind of similar. But in the end, a link should take you to a new website, to a new address, while a button is there to trigger some interactivity. So in earlier days, when buttons were not able to be styled using CSS, like in Internet Explorer 6 or something like that, many people just took links or even diffs to kind of mimic buttons. And I think that's the background here, the history why still some web experts feel that they should just use links instead of buttons. And that's just not the best way, right? So if you wanna send your user to a new website, or just like a new page on your website, then you should use an anchor tag with an href attribute. And if you wanna trigger some interactivity, like opening a dialogue or opening and closing a menu, then you should use a button. I hope that answers, Rashmi. Anything else? Yes, no. Cool. So one more question that we have is, you mentioned in our talk as well that many seasoned developers make this mistake of not including accessibility practices in their coding. So for a person who has been coding for a long time and has not considered to include all of these, how would you advise that person how to go about that and how to start including these practices? That's a good question. So I don't wanna make too much self-promotion here, but it's actually the mission that we had when we were implementing the Accessibility Developer Guide. It's targeted at experienced users who already know a lot of web design and how to program and code, et cetera, and just want to level up their skills and take accessibility in mind. So I really can advise, let me just show the slide if I find it here again. So it's this one. The Accessibility Developer Guide, just go to accessibility slash, no, not slash, sorry, hifendveloper-guide.com and there, let me just introduce you for a moment to the project because I feel it's like it's just the right entry point for seasoned people, right? So we have like this introductory part, we have the setup where you are guided through creating your own setup of screen readers, browsers that you will need. It's quite a lot already, just to be able to do accessibility testing. You need a Windows virtual machine, probably. You need the right browsers like Firefox and you need screen readers, probably you will need NVDA and JAWS, but also talk back on mobile and voiceover and maybe even voiceover on your Mac. So it's a lot of things that you can figure out yourself and it took us years to figure out these best practices or you can just head over to this guide and implement those. And then in the next part, we have a lot of knowledge, like what about contrast and colors, what are semantics anyway? I think so many seasoned web experts are using HTML and actually don't really have a clue what semantics are that they even are, but they exist in the first place. It's not optional to use a heading for a heading. It's just how HTML was intended to be used, right? We have a section about ARIA, about keyboard only usage and screen reader usage. And then we have a lot of examples, how to create good heading structures for your website, how to implement accessible tables, how to create forms with validation messages, et cetera, et cetera. And then the widgets. We have widgets for tooltips, tablets, whatever, quite a lot of things here to see and they are meant for inspiration. Go there and be inspired and then create your own solution because I'm pretty sure it will open, it will give you quite a few flash bulbs in your head when you read through the guide. Yeah, that's a great resource. I'm definitely checking out accessibility developer guide right away. One last question for you is how to go about accessibility audits for websites? Like, who do you want to share your experience and how do you think we should go about it? So back in the days, like eight years ago, when I started at Access for All, there were not many tools that we could use for audits. And we learned to do audits just manually, fire up a screen reader, test the website, try to use a website using keyboard only, look for bad contrasts, et cetera, et cetera. So it's kind of a toolset which is, yeah, it is quite a lot to learn in the beginning because there are other areas like video, you need to make sure that there are closed captions, audio description, et cetera. You can expand it to PDF, so it's quite a big world. But luckily today, there are quite a few tools which assist you. And I would suggest you to use a tool which does automatic testing for you in the first place, but also helps you to do manual testing. Never trust a tool which tells you, I'm gonna do an audit for you, and that's all you need. This is just not possible and probably will never be possible because accessibility has so much to do with very distinct and, yeah, it's just, it's a very humane topic. You can't just write some technical rules and test everything automatically. So I think if you really want to become a seasoned accessibility developer, you will have to learn some of those tools, especially how to use a screen reader. But get yourself help with the automated testing tools that there are, for example, tenon.io, I guess, is a good one. There are quite a few at the moment. There are even three ones which you can run in your browser, like the AXE or AXE, I don't really know how to just call it in Chrome. There are a lot of tools, too many tools in my opinion. But yeah, get inspired. Yeah, I mean, like a lot of developers are often worried about how fast is their website. They often do that sort of testing, but they must do an accessibility audit. That was totally, totally. I always say, if developers or designers would invest just a fraction of the time they invest for creating pixel perfect, beautiful, stunning visual experiences, then we would have a much better and much accessible web. That's such a good advice. So, at least you raise your hand, you want to add in something or ask something. Yeah, yeah, Joshua. So this one just question me means you talked about accessibility guide that you prepared, but so do we, do you have any reusable pattern library that you have created using the native HTML? You know, that is really helpful to some, you know, the budding developers or something of that sort. Yes, we do. Not in the sense that it's just like a JavaScript library that you can just like link to from your website, but all of our topics that we have in our accessibility developer guide, they have real, real life examples in there. Very simple, for example, the headings examples, a good heading example, just very basic headings just to get a picture of what are good headings. Then we go more deeply into the topic. We show how to visually hide headings. So that a heading structure still makes sense, but does not distract the visual appearance. And all of these examples you can click on and then you have them like traditional HTML elements that you can play with, that you can interact with using a screen reader. It's all made for kind of creating the smallest pieces and bits that are important and relevant from an accessibility perspective, so that even users who do not have a lot of experience can just play with it and see and look into the DOM and see what JavaScript is doing there so they can see what is going on in the end. So you get a lot of inspiration here, but it's not something that you can just copy and paste to your own project kind of. Does this answer your question? Yeah, I think it was great. One last question. I think your presentation was so awesome that people are going to ask a lot of questions and they appreciated you in the chats as well. So one last question from Krushna. He goes on to say that when developers are working on legacy systems and there's a limitation that you can't use semantic elements, how to go about with that. And in continuation of the same, he says that on the contrary, when we're using external JavaScript API like ReactJS or any open UI framework, they automatically provide div blocks to the DOM tree for any semantic control. So how can you restrict that? Yeah, these are two important questions. So the first question, if you are implementing a web app or a website for a legacy system, you should stick to the selection of features that are kind of provided by this legacy system. It feels absurd to me to have to wish to create a full-fledged modern application inside a restricted environment So I would rather try to rethink whether those features that you are trying to implement are actually needed and rather adapt the usability and the interaction patterns to the, yeah, just to the basic basis that you have with your system. And as you have seen, I mean radio buttons and stuff like that, they were here like decades ago. You can do a lot of stuff with those. Probably it's not the legacy systems which introduced the problems, but just like bad coding or like unaware coding and trying to pack too many fancy interactive options into your project, which in the end might not be even necessary, which in the end might even be like confusing to many users because they don't know our drag and drop, what's that? Oh my God. I'd rather just have a button here and a native drop down there. And that's all that I need. I don't need any flashing and moving around stuff. I'm exaggerating a little bit, but I think we get the point. And the second question, this is one of the main problems, I guess, that many seasoned web frameworks from Google, Angular, View, you can name all of those react. Many of them, I mean, they are trying. They are creating better experiences today that they did a few years ago, but still a lot of them are just, sorry that I said, they are just creating shitty HTML. And it's kind of the only thing that we can do there is to make those people more aware of the topic, I guess, and try to push the topic inside those communities. That's more or less if you try to optimize such bad code and throw in a little bit of Aria here and a little bit of semantics there, usually it's not gonna become much better. Sometimes it's getting even worse.