My name is Gian Wild. I'm from Accessibility O, and I'm here to talk to you about accessible JavaScript. It's easier than you think. There are three types of JavaScript functionality. First, binding functionality to existing interactive components such as links, buttons, and text fields. Two, non-interactive functionality that presents information. Three, creating custom components that are both interactive and informative. There are 10 accessibility principles when it comes to JavaScript. First, all functionality must take a form that can be interpreted as text. Second, all functionality must be accessible to all input devices. Third, information and structure can be programmatically determined. Fourth, a meaningful sequence and logical focus order is maintained. Fifth instructions Do not rely on sensory characteristics or nonsensical characters. Sixth timed activity can be controlled. Seventh, provide mechanisms to help people find and interact with content correctly. Eights do not cause a change of context or content unexpectedly. Ninth, identify components consistently and tense. Identify and describe errors and error suggestions in text. Now this is quite a complex presentation. There's a lot of information in here, but don't fear all this information is in what we call the accessibility Oz JavaScript fact sheet. And if you go to the Accessibility Oz website, you'll find that there is a section called fact sheets, and underneath it there is a JavaScript fact sheet. There's also a heat more on other topics that you might be interested in. And if you go to this JavaScript fact sheet, you'll see there's a section here on accessibility principles and the impact on users. So you know what happens when your system is not accessible. Manage a checklist, which is basically a testing checklist, and you can actually go through this and determine, does all dynamic visual information have a text equivalent? Eg. A visual progress meter also shows a percentage figure. And if you're like I don't really know how to do that, then if you have a look at the developer. Checklist. You'll see that there's some correct examples. There's also some incorrect examples in some cases, and if you go to that, there's an appendix and there is actually a live demo with all the code available that you can copy and paste as required. And this is what the live demo looks like. So there's lots and lots of information there. Don't fear if I'm going a bit fast or you're a bit worried that there's just a little bit too much information in this presentation. The presentation slides will also be available. They are, if you go to the accessibility Oz website and you go to about, and then conferences, you'll find that here we've got the Comp 42 JavaScript conference. Once the. Conference has finished. It will end up sitting under this, heading past conferences and events 2025, and I'll add the PowerPoint presentation there. So let's talk about the types of different JavaScript functionality. Type one, as we said, binding functionality to existing interactive components such as links, buttons, and text fields. So assistive technologies can derive information from their attributes and text. For example, a dynamic menu would be made using. Organized with nested lists in which the menu levels are denoted by the hierarchy and by the use of structural labels around each top level link. Type two non-interactive functionality that presents information. So this must be implemented in such a way that the information can be derived from associated text as I just showed you. A visual progress meter would also show a percentage figure or JavaScript might be used to identify and highlight form validation errors. And type three, creating custom components that are both interactive and informative. So these components must be implemented using elements that are already understood by assistive technologies so that their content and interactions can be programmatically determined. For example, a calendar widget would have a label to describe it and a button to trigger it while the calendar itself would be made of table markup, which assistive technologies can understand and interpret as structured text. Principle one, text alternatives. People with disabilities may rely on assistive technologies such as a screen reader, a braille reader, or a speaking browser. These technologies represent all information as structured text. If visual information has no text equivalent, assistive technologies will not be able to relay that information to the user. And also if interactive components do not have a descriptive label. People who use assistive technologies or who have a cognitive disability may not understand what it. Now, if you got to this part of the presentation and you've gone, what are assistive technologies? I don't really understand all this accessibility stuff, then the best thing to do before you watch the rest of this webinar is to watch the Accessibility Basics webinar. It's on YouTube, www.youtube.com/watch. Question mark v equals. YS, capital T, capital D, capital A, lowercase U, the number two, lowercase Z, uppercase V, lowercase I, and uppercase M. And if you like me and you actually don't like watching videos too much, you can also read the Accessibility Basics article, which is at TinyURL com slash a1 y basics. Of course the worst example of this principle is they capture in case you don't know what a capture is, this is what a capture is. Basically some gobby book test that you need to type in, and it's inherently inaccessible for a lot of reasons. Even if it has an audio version, and yes, Google's recapture. You know that little ticky thing that it just determines automatically if you're a bot or not. That's also inaccessible because the recapture thinks that people who use technologies are bots, so of course it doesn't work. And then it says, Hey, pick the buses out of these nine images, and people are blind and they can't see the buses. Anyway, that's a whole nother story. If you wanna learn more, have a read of the article I wrote recently. Gold, the inaccessibility of capture. The URL is tiny url.com/ 2 0 2 5 dash capture. This is a better thing to use instead of a capture. Basically something like a human test question. You can also have honeypots where you have a field that has to be left empty and you can have that in the field label. You can hide it so people can't see it, et cetera, et cetera. There are a lot of things that you can do. Multifactor authentication, as I said, I could talk forever. Just don't use capture. If you only take one thing from this presentation, it should be don't use capture. The other issue is visually dynamic content. Of course, we saw the visual progress meter that the accessibility of fact sheets have. I just wanna show you an incorrect example, and this is an incorrect example. As you can see, it does display the status, but it does so using. Only a visual medium and color contrast doesn't really work either. This is a much better progress bar. As you can see, you've got text. Of course, it changes quickly, but that's okay and that is a more accessible progress meter. Another thing to be aware about is image buttons. I know people don't use them a lot anymore, but there's still a few. Once again, your correct example. Of course, I know they aren't used so much anymore, but this is a correct example. You can see the image button has the text of search, incorrect example. The image button has a text of sub. Not very useful. Complex content, functionality that can't be made accessible. Must have a long description that provides the same information. This is an example, once again from the JavaScript fact sheet. Very complex information, a Google map, and it has directions. Now, it's important when it comes to creating alternatives for complex content. It's not about providing all the information that's in the image, it's providing the relevant information. So this is about. Having directions from Sydney Road to Smith Street. So the long description says one head South on Sydney Road State Route 55 toward Mary Street for 550 meters. Turn left onto Brunswick Road State, route 38, then proceed for 1.6 kilometers. Turn right onto Nicholson Street, then proceed for 1.5 kilometers. So this is basically something that you need to do. It's not a JavaScript thing so much, but if you have something complex, can't make it accessible, provides a lot of information, make sure you have that long description. So basically, the text alternative requirements are image buttons must have a valid alt attribute. Any images conveying information must have a valid alt attribute. Submit button is an image. Then it must have an alt attribute. Captures shouldn't be used. If they do, you need to have multiple sensory modalities and complex systems. Must have a long description if you're not really sure about this whole interactive maps, creating a long description. We do have an interactive maps fact sheet at www.accessibilityoz.com/fact sheets slash interactive dash maps. Two, all functionality must be accessible to all input devices. What are input devices? The standard input devices are a mouse, a keyboard, and a touch screen, whether it's on a mobile device or on a laptop. And then there are assistive technologies that mimic input devices so that people with disabilities, they cannot use a particular input device because of, say, a physical disability. They use what is called an assistive technology, which often mimics one of the standard input devices. So for example, the joystick mimics a mouse, an onscreen keyboard mimics the physical keyboard, external keyboard on a mobile device, mimics the keyboard thumb switch, mimics the keyboard, head wand mimics a mouse. Principle two is about input device accessibility. Assistive technologies are usually controlled with a keyboard rather than a mouse or a pointing device, and there are many people who are simply unable to use a mouse or a track pad or a keyboard because of a motor impairment. If interactive content. Can't be operated with a keyboard. It will be entirely inaccessible to people who can't use a mouse or pointing device. There are also people entirely reliant on other input devices, so it's essential that all the site functions using only one type of input device. So let's talk about the keyboard. When you are using the keyboard, people use tab to move between actionable items, escape to close a feature, and arrow keys as well, to move amongst things. If you have a complex feature and there's an unusual way to close the feature, then you must document what that feature is before people actually get to that feature. You should also be able to tab from start to finish, not be trapped in some kind of component. That is one of the most serious accessibility issues is the keyboard trap. So all interactive content should be accessible to the keyboard using common keystrokes like tab and enter and arrow keys, and you need to be able to move through. In the late two thousands, it was very common that any video player in Firefox was a keyboard trap. Users would tab into the video player to play it, or just because it was on the screen and they couldn't exit the video player, so they got to the end of the video player and the tab key just basically stopped working. And so what they would have to do is they'd have to close the browser and reopen the page and try and avoid that video. That's a major accessibility issue that you absolutely want to avoid. To learn more about keyboard, there is a keyboard fact sheet. Have a look@wwwaccessibilityoz.com slash fact sheets slash keyboard, and there's also a video on keyboard focus. It's at www do accessibility oz.com/resources/videos/keyboard-focus. So some examples. First off, we talk about keyboard focus indicator. Do not use events to restrict keyboard access or remove focus indication. Therefore, don't use on focus equals this blur. And I'd like to show you a correct example in the. If we start at the top of the page, you can see that the keyboard focus is now on skip to the content, and then it goes to language login site, map, a SL videos on the right hand side. The next thing to get focus is the logo. The search bar. The search button, and then we have the menu. So you can see it's very obvious where your keyboard focus is. It is very easy to move around the site. So dynamic menus need to be fully accessible to the keyboard using tab and arrow keys, and I'll just show you an example of that. Now, here we have the Accessibility Oz website, and once again you see where the keyboard focus is and you can tab across the main menu items in the navigation. And if you actually wanna look at sub items under the menu item, then you just press the down arrow key and you can move through the items. Another example here, JSNA one. So this is part of the JavaScript fact sheet. Basically, you can use the tab keys or arrow keys to move around. I'm using tab at the moment, but I can also use the down arrow if I want to. Keyboard requirements, there must be no keyboard traps when creating a motor window dialogue box focus, et cetera. The keyboard focus must be trapped within that dialogue box. You must of course, also have a way to close that dialogue box once the user has finished with it. Dynamic menus must be fully keyboard accessible. Anything that has mouse only functionality needs to have a keyboard equivalent and make sure everything has a keyboard focus indicator. So that's about keyboards. There are a whole different bunch of other requirements around touch screens. When you think about a mobile device, you do a lot of things much differently than you would do if you were using a mouse, for example, two Pink zooms, swiping up and down, et cetera, et cetera. There's quite a lot of rules and regulations to make sure that mobile sites are accessible, including native apps. Best thing to do is have a look at the mobile accessibility guidelines. It goes into a lot of detail into how you can make things accessible, and that is available at www.accessibilityoz.com/resources/mobile-testing. Information be programmatically determined. If scripting is used to implement standard functionality, technologies will not understand it and be or provide the appropriate if custom widgets are built, using technologies will similarly fail to understand what they're. When content requires user input, labels or instructions should be provided to assist the user with completing their task and to minimize mistakes made. For example, if labels and instructions are not provided and associated with a form input, a blind user will not know what information to enter. Similarly, labels and instructions that are not visually located closely to a form input can prevent users of screen magnifiers and people with cognitive disabilities from seeing this information. Labels and instructions that do not give examples of expected user input can reduce the likelihood of users with cognitive language and learning disabilities entering the correct information. Keyboard. Users may submit incomplete forms if required fields are not labeled. Trying to find the incomplete input is a tiresome task when information is not provided to assist. So let's talk about labels and field sets. Fields must have an associated and coded field label. A good example of this is Amazon. So if you go to the Amazon website and see we have a field here, and if we right click that field and select Inspect, you can actually see the code at the bottom of the screen. Here you see we have input type email because it's an email address. And it has an ID of AP email. If we look at the label, it has a label four of AP email, and that is how the two are associated. Another thing to be aware of when creating forms is the use of field sets. So field sets are for grouping fields only. There are three ways fields can be related. First, they belong in one particular group. So for example, you're searching and there's a bunch of search options that you can choose from. All these search options, they're the same thing. So actually having them grouped is a good idea. Another reason why you might wanna use field sets is because a field doesn't make sense without another field. So here we have a phone number that has two fields. The first field is for the area code. The second field is for the phone number itself. Of course, without an overarching phone number field set, those two won't be clear to the user. Thirdly, they only make sense in conjunction with an overarching heading. For example, if you have a list of states and you have a list of check boxes, then all those check boxes are related and they have an overarching sort of name of state. So you want the states to be grouped with a name of state territory. For more information, have a look at the accessibility Oz forms fact sheets, www.accessibilityoz.com/fact sheets slash forms. A series of videos on forms on the accessibility website. The URL is www accessibility oz com slash videos. And if you go to the accessibility S website, you can see there's a resources main menu, and then there is the link C, C, C developer videos. And if you go there, you can see that there are videos on H, TM, L forms, and Aria. The videos on forms include explicit and implicit form labels, which we just talked about field sets and legends, which we also talked about. Check boxes and radio buttons. Required form fields, accessible form instructions, error messages in forms, and accessible session timeouts. Next we're gonna talk about accordions. This is actually a requirement under bypass blocks, which is used an expandable collapsible menu to bypass blocks of content. And I'll show you a couple of examples. Is the Transport Accident Commission website, and you can see here they've got an expandable menu. So a couple of things about this expandable menu. As you can see, the arrow changes when it's expanded and when it's not. If you use the tab key, you'll find that you can access the accordion using the tab key and all the content underneath using the tab key. It meets accessibility requirements, et cetera. This is another expandable, collapsible menu from the JavaScript fact sheets. This code, you can actually use yourself if you would like to, and so once again, it is accessible via the keyboard. You can open and close it when it's closed. You can't tab to the sections underneath. When it's open, you can. There's also a great section in the Aria Authoring Practice Group about creating accordions and doing so with Aria. The URL for that is tiny url. DO com slash a1 y dash accordion. And remember, accordion is spelt with an O and that's what it looks like. Once again, no aria is better than bad aria, so make sure you know a lot about Aria before you start playing with it. But here is an example, talks about the role states and properties and keyboard information, and it has quite detailed. Code as well can help you. Principle four, a meaningful sequence and logical focus order is maintained. The visual reading order of form content or your JavaScript content should be presented in a meaningful and logical sequence. IE left to right and top to bottom, assuming of course, a left to right language. Screen readers will read form components in the order that it appears in the source markup. In fact, they read everything in the order that it appears in the source markup. When meaningful sequence is not maintained, form content may be displayed incorrectly when presented in alternative formats for assistive technologies. Users of assistive technologies sometimes do not have access to the entire page at once, so changes before the user's current focus or elsewhere on the page may be missed. Navigating with the keyboard is a one dimensional process, and users who rely on speech output can only hear one thing at a time. So content that is not in a logical order is harder to comprehend and use. When a keyboard user presses a button and new interactive content appears, they'll expect that content to be immediately next in the tab order not to have to jump around the page to get to it. The other thing to remember is that websites are accessed by a variety of devices, including mouse, keyboard, touchscreen, switch, joystick, and assisted technologies such as screen readers and magnifiers. When the source order, keyboard focus, order and visual reading order of a webpage are inconsistent with each other, this can greatly impact people's ability to navigate and access a webpage effectively. So there are basically three orders that you need to be aware of when creating a webpage or a native app or anything like that. The first is the source order, which is the order that the underlying HTML or other markup is written. Secondly is the keyboard focus order, which is the order of interactive page elements such as links and form controls when accessed by the keyboard, IE, the order in which items receive keyboard focus. You can easily find out what that is by going to the address bar and hitting tab and. Heating tab again and going through your page. And thirdly, visual reading order. The logical and intuitive order in which a cited user naturally reads the page content. This is generally left to right and top to bottom, and all content should be presented in a meaningful sequence so that any relationship within the data is clear. If you'd like to learn more, there is a source order fact sheet and the accessibility Oz website. You can go to www dot accessibility oz com slash fact sheets slash source order. There's also a video about this called source order versus display Order versus Keyboard Focus Order, and you can get to that by going to tiny URL com slash three dash orders. Now when we're talking about visual reading, order sequence also really matters. This is an example where visual reading order is very problematic. As you can see, you've got the ability to purchase tickets to the Lion King, but it doesn't say anything about say, accessible tickets. It's because that information is after the submit button. Here you've got request accessible tickets and a whole bunch of other information, but information should never be after a submit button because of course, the submit button is when people, they leave the page, and that's for everyone. Screen reader, users, visual users, et cetera. This is another example where visual order is problematic. You've got a book here, all the light we cannot see on Amazon. And you have these prices, but these are not links, so you can click on it many times and nothing will happen. And only if you look over here on the far right hand corner does it say This title is not currently available for purchase. Now this information should be first up. People will often miss content that's on the right hand side, especially magnifier users, but visual users as well, and screen reader users because they're gonna have to read all this content first, all the way down the page through the comments and other things that you might be interested in, et cetera, et cetera, before they get to the about how you can't actually purchase the book. Let's talk about focus order. So it's important that when you do insert dynamic content, you insert it into the dom immediately following its trigger element. Let's have a look at an example. This is an example from the JavaScript dependencies, and here you have a live demo. You have a link here, structural labels, which if you click on, you'll actually pop. As you can see, the additional information appears immediately after the link that generated the change. Another example is this re sortable list. Once again, let's have a look at the content. If we expand it, you can see here. Lauren Ipsen is first said, probably said that wrong, is second. Pre-order the content and then you can see the said is first and the Lauren Ipsen is second. This is another example where you can move items with the keyboard up and down the list as you can see. And once again, if we have a look at the dom. At the moment, you can see New South Wales is first, but let's change that. And now we've got South Australia as first. This is how you make sure focus order is correct when you are creating forms. You don't validate on completion of a field. You validate only on submission of a submit button. So you can see here someone's put in a desired login name, they've hit check availability. This is done by JavaScript so the page doesn't refresh. But immediately next in the dom, have they added this content? Janet Whitman is not available, but they're following usernames are, and then it gives some examples. Next is principle five. Instructions Do not rely on sensory characteristics or nonsensical characters when sensory characteristics, color, shape, and location, or nonsensical characters, asterisk, dashes, et cetera, are used instead of text. Users of screen readers may not be able to understand the meaning of the content. Often these are ignored by the screen reader, which means information is omitted completely. So let's talk about fields. This is an incorrect example. Basically, the fields that are in error are marked in red. Now, that's gonna be really problematic because the reader doesn't read out color. But it's also gonna be problematic for people who are blue, red, colorblind. They aren't gonna be able tell the difference between red text on a white background and black text on a white background. So they aren't going to be able to tell which fields are mandatory. Next is principle six. Timed activity can be controlled. Users of assistive technology often take a lot longer to read a page or undertake required functionality, either because of a cognitive disability or because they can only focus on a few words at once. Or because it takes longer to listen to synthesized speech than to visually read. It would be confusing and disorienting for people if content were to change while they were reading it. Continual animation or flickering effects may trigger a seizure in someone who has photosensitive epilepsy. It's also more difficult for someone with a cognitive disability to ignore these effects, which makes the actual content harder to focus on. So let's talk about flickering. This is an example of if you fail a particular accessibility requirement, you can actually physically hurt someone. The best example of was back in 1997. An episode of the anime series Pokemon was shown was the 38th episode of the Electric Soldier Pogon Series broadcast in Japan on December 16th, 1997. On 37 stations to 4.6 billion households. There were repetitive visual effects, flashing red and blue, effectively strobe at a rate of 12 hertz for six seconds. Basically no flashing, flashing images, especially those with red, should not flicker faster than three times per second. If the image does not have red, it should still not flicker faster than five times per second. Flashing images should not be displayed for a total duration of more than two seconds. Stripes, swirls and concentric circles should not take up a large part of the web screen. Now, of course, you might read that and go I dunno what that means. So the best thing to do to determine if your content has flickering is to use the peach tool, the photosensitivity epilepsy analysis tool, and this is the output of that particular Pokemon episode. As you can see, there's quite a lot of red, not so much green. You can access for free at traced edu PT. And if you wanna see an example, which I'll not show you, the Kickstarter campaign for LX has some flickering content that fails. It's a campaign for light bulbs, and also if you have a look at this Teletubbies image, you can imagine if it was moving, it would be fairly problematic. Next we wanna is time limits one user when a time limit is about to expire and provide a mechanism for extending it. This is also from the JavaScript dependencies. There is a time limit, as you can see, says your session is about to expire. Do you need more time hit? Okay. And of course, the JavaScript code is there. Another example here is incorrect, and here it says, these are currently the best available tickets that match your request. These tickets will be held up to eight minutes for you to complete your purchase after which time they'll be returned to sale. So that doesn't allow anyone to extend the time, and so that is a failure. This is another example. Make a donation. Your session has timed out. You need to start ag. Good luck starting one of me and complete the members form within 20 minutes. Which really begs the question, why does anyone have a timeout on a donation form? It's give us your money, but only within the next 20 minutes. Next is movement. Use scripting to scroll content and provide a mechanism to pause it. And this is the JavaScript appendices example. As you can see, the flickering content, which stopped within five seconds. So if you really need to use some blinking information, you can do so using JavaScript. Do not use the blink element. And then there's the Accessibility Odds website. You can see we have a slideshow. It's fairly slow, but you can pause. It can move things across as you like. You can move through it and you can pause or play it. Incorrect example. So this is basically just scrolling content that just keeps moving from one thing to another. The first one says traveling halfway around the world, just hang out with other. And the second is bid proved we're not ready to host the globe, but there's no pause button. This is a correct example. Monash University as you can see, it has play button, a pause button, and the 1, 2, 3, 4. So you can choose one of those options. Another way to deal with this is to provide alternatives to moving content, so you could use scripting to create an alternative static version of scripting content. Once again, this is the JavaScript appendices, and as you can see, we have some scrolling content. Very difficult to read for a number of users, so you can pause it. You can even expand it so it's all written at once. Once again, you have the code there if you need it. Redirects are okay if they're on the server, but timed redirects on the client side an absolute no. So the rules are timed, server redirects not allowed. Timed client side redirects not allowed. Non timed server redirects are okay. Animated GIF must stop moving within five seconds. Do not use Blink or marquee. Make sure you can stop moving content with the user agent stop button or the escape key and or reloading the page stops the blinking and or there is a link to stop content. And of course, you also need to be able to stop that content using the mouse. Principle seven provide mechanisms to help people find and interact with content correctly. People rely on mechanisms to find information that are most suited to their needs. On a large website, if a search is not provided, blind users may find it cumbersome to tabs through a large navigation block. Or visually impaired users may find it difficult and confusing when doing the same with a screen magnifier or screen reader. Providing a search benefits everyone by allowing information to be found quickly. In addition, it may be obvious to you how a system works, but that's not always the case for everyone and for people with disabilities, often contextual information like imagery. May not be available or an alternative presented. Therefore, it's important to always provide instructions on how to use unusual content or functionality or on how to use functionality that does not operate as the user expects. So instructions are really important. Even if you think it's really clear to you, that's not necessarily gonna be the case to everyone. So this is a magazine and it provides quite in-depth instructions on how to turn the page, et cetera, et cetera. Just remember that all this content needs to be accessible to the screen reader as well. One example of this is functionality that can't be presented in text must be descriptively identified. This is an example of functionality that can't be presented in text. Button will appear below this text within the next 20 seconds. You should click the button as soon as it appears to test your reaction time. And of course, this is only affected for sighted mouse users. It's not gonna be great for someone using a keyboard or someone who uses screen reader Principle eight. Of context or content unexpectedly. Navigating a document or inputting data into a form should be a predictable experience for all users. People with visual, cognitive, or motor impairments may become disoriented. If changes in context or content occur unexpectedly, such as a new window popping up, or the focus being moved to another form component, the user may not be aware that change has occurred as a result of their actions if they were not adequately informed or did not initiate the change. So one example of this is opening content in new windows. Make sure you use an actuation event rather than focus or load to programmatically open links or trigger popup windows. This is another JavaScript fact sheet. Now, it's not gonna actually open a popup window because I have them disabled, but basically if you click on this, you'll end up getting a popup if you have that kind of stuff enabled on your site. Next is use progressive enhancement to open windows on user request. So this is the JavaScript pen, and if you click on this link, it opens up in a new window and you can have a look at the JavaScript content there. Let's talk about change on user request. So make sure that you do not use the change event of a select element for navigation. Let's have a look at an example. If we look here, we've got a jump to. And we can go down and we can select something. Now, it's not common usage to select something and it automatically submits. If you have a select box like this, users expect there to be a submit button. But if you select an option, you can see it takes you to that page immediately. Another example here is if you select your area, it will open a new page immediately instead of giving you a submit button so the user can choose when they wanna move to a new page. Another is do not automatically refresh the page without user confirmation or control. And you can actually do this is a failure. This is incorrect code. The link will take us to a page containing a large number one, and then redirect to a page with number two. And as you can see, that was a client side redirect. Very bash. This is an example. I've only seen this once, but I have to use it as an example. You can see here you've got rollover for video. So if you just move your mouse over that, all of a sudden this entire video pops up, which is very distracting and will be incredibly inaccessible for users. A correct example where you are doing the automatic filtering is when you enter content into a field and it filters automatically. This is not something that users expect, so you shouldn't do it. But if you're gonna do it, you need to absolutely include instructions prior to the form field. So here it says the list of outages will automatically begin to filter once you enter some text in the filter outages by suburb field, and the field is immediately after that text. This is a popup, so we've put in some content for Twitter. I refuse to call it whatever the other name is, and it says, Hey, your tweets being posted, and this is a popup on a page. And then after a couple of seconds it just disappears completely inaccessible. Do not do that. Principle nine is identify components consistently. Functionality that is similar or used more than once on a website should be labeled consistently to create familiarity and ease of use. This improves a user's ability to find information or use similar functionality on other pages without having to relearn how this is an incorrect example. Basically inconsistent pagination. These are from the same site, and you can see that they look quite different. The first is all just text, same color. The links that are actionable are underlined. The second, none of the links are underlined, and you also have what seems to be a next button. So this is the kind of example of inconsistency that you want to avoid. When it comes to forms, then you also wanna avoid inconsistency as well, whether it's buttons or shape of fields or things like that. But this is another example where the contextual help is inconsistent. So the very first contextual help is just text under the field. The second contextual help is a little information icon that you can click on and get additional information. And the third contextual help is just a popup that appears randomly. You need to make sure this is consistent. And finally, principle 10, identify and describe errors and error suggestions in text. When an error is detected, it should be identified in text and described in detail without specific information about the error. Screen reader. Users may believe a form is not functioning and may abandon it altogether. Errors that are identified with color alone or symbol or icons may not be understood or recognized by users who are blind or colorblind. This may also be the same for users with learning or language disabilities, or other cognitive impairments. When error messages are provided, they should include suggestions on how to correct mistakes such as examples of the correct user input without suggestions. People with visual or motor impairments or cognitive language and learning difficulties may not understand what the required input is and may not be able to correct their mistakes. After repeatedly trying to input the correct information, which can be very tiresome, users may ultimately abandon the form altogether. When a form is used to initiate a legal or financial commitment, or to modify or delete user data, a step to reverse check or confirm the user input before submitting the form should be provided to prevent users from making a serious mistake. Users with visual or cognitive language and learning difficulties may have input incorrect characters or users with a motor impairment may have hit incorrect keys. Field errors is one example. Form validation should always be triggered by submission rather than individual field events. Form validation should trigger an alert. Then set focus on the first invalid field. Validation error. Messages should be programmatically inserted directly after the field. They relate to using functions of the dom and in the label element. So let's have a look at some examples. If you enter some text, let's enter some text and then tab to the next field. You can see there is field validation immediately after the field. This can be very confusing for screen reader users, especially if you then trap users in a field that isn't correct. This is another example. If we just enter some random content and then hit submit. There's some text at the top that tells you what's wrong, but the focus is actually still on the submit button. So you wanna move focus to where the errors are. We have some information in the JavaScript fact sheet about this, and this is correct. You can enter some text and then leave the other one empty and you can see it will say, Hey, you got some errors and it's moved you to the field in error and given you an error. Error form. Submissions should be bound by the form submit event, not to the submit buttons. Click event. Incorrect example is input type equals submit. On click equal return validate this correct example would be form action equals search on submit equals return. Validate this and do not force focus to remain invalid fields. Let's have a look at an example here. We have a field. I'm gonna type in some text. I'm tabbing, and as you can see, it won't let me. Where form fields require a specific format or range of values. Contextual help text can be programmatically inserted directly after the field. It relates to using functions of the dom and in the label element. So let's have a look at that. As you can see here, as you tab from item to item, you get a popup with some information. So when it comes to error identification, the error must be in text, be it the relevant field, be included in the relevant label four element. This is an incorrect example. As you can see, the fields have not been completed, but the form has been submitted and all the errors are underneath the submit button. This is absolutely problematic if you're gonna do everything in JavaScripts because as we said before, no one looks past the submit button. A much better example. Once you have submitted an empty field, you can see that every single field that requires information has some field labels. Now, all this information is in the forms fact sheet@wwwaccessibilityoz.com slash fact sheet slash forms, and we do have a series of forms videos, www accessibility oz.com/videos. And if the information isn't there, it'll be in the JavaScript fact sheets and associated appendices, www accessibility s com slash fact sheets slash JavaScript. In conclusion, as we talked about, there are really three types of JavaScript functionality. First binding functionality to existing interactive components such as links, buttons, and text fields. Non-interactive functionality that presents information and creating custom components that are both interactive and informative. There are 10 accessibility principles. All functionality must take a form that can be interpreted as text. All functionality must be accessible to all input devices. Information and structure can be programmatically determined. A meaningful sequence and logical focus order is maintained. Instructions do not rely on sensory characteristics or nonsensical characters. Timed activity can be controlled. Provide mechanisms to help people find and interact with content correctly. Do not cause a change of context or content. Unexpectedly identify components consistently and identify and describe errors and error suggestions in text. Now, I know that was a lot of information, but there are lots of places where you can find additional information. Have W3C Aria Authoring Practice Guide the Patterns section. It has information on how to create accessible accordions alerts, alert and message dialogues, breadcrumbs, carousels, check boxes, combo boxes, dialogue models, sliders, switch tables, tabs, toolbar, windows, splitters, and many more. The Authoring Practice Guide also has practices section, which has information on landmark regions, providing accessible names and descriptions, developing a keyboard interface, grid and table properties, communicating value and limits for range widgets, structural roles, and hiding semantics with the presentation roles. All that information is available at www w three org slash slash apg. And of course there are the accessibility odds fact sheets. We have them on a range of topics, including images, P video, interactive maps, H two ml five, content, JavaScript tables coding, keyboard source order, and forms. Those are available at www.accessibilityoz.com/fact sheets, and then there are the accessibility OZ developer videos. In the HTML section, we have HTML headings well-formed and valid markup, keyboard focus, source order versus display order versus keyboard focus order. In the form section, we have explicit and implicit form labels, field sets and legends, check boxes and radio buttons, required form fields, accessible form instructions, error messages in forms, and accessible session timeouts. And in the Aria section, the videos are what is Aria and why use it, how not to use Aria. Aria Landmark roles, aria labeled by versus Aria, described by versus Aria label and using Aria Live. All those videos are available on www accessibility oz.com/resources/videos. And then there are the mobile accessibility testing guidelines. There are guidelines on both native app and mobile site. Devices capture error technologies and step by step instructions with examples that's available at www accessibility resources mobile testing. Thank you for coming along. You can access these slides at www accessibility oz com slash about slash conferences. Just look for the comp 42 heading and I'll have the presentation slides there. And please if you have any questions. Please do reach in QE and if you have accessibility, please do reach out. We're always happy to help. Thank you very much.