Accessible Web Mapping Apps: ARIA, WCAG and 508 Compliance

I hope you're all here for accessible web mapping apps Aria Wicca and 508 compliance my name is Kelly Hutchins I'm a product engineer on the RTF API for JavaScript team and I also work with artists online configurable app and I'm joined by my colleague Tao hello my name is taja I'm a UX architect for ArcGIS online and then also responsible for doing accessibility work at primary online and JavaScript API so this is the agenda we just want to do the little introduction we'll talk briefly about what 508 Inwood KAG are if you already know what these are it's only like a five or ten-minute section so we'll get to some more technical stuff after that we'll go over making accessible components we'll do some demos we'll show you some automated testing tools and we'll talk about some accessibility resources that you might find useful so there are a lot of people in this world with some form of disability you'll see numbers like 15% of the world population which equates to about 1 billion people so when you follow these principles of designing for accessibility you're actually reaching or building for a big population of people and as you'll see I think the number is even larger than that I kind of feel like it's building it for everybody the forms of disability are classified as these four groups visual motor auditory and cognitive the visual is this range from completely blind to some sort of vision loss so I'm getting older and as I get older I find that I can't see things as well so I think just last week on my iPhone I went into the accessibility settings and turned on the large text just because I found myself squinting at my phone all the time so it's sort of a continuum and we all maybe we'll be facing these issues as we age not being able to see as well or maybe you forgot your glasses or you're trying to look at a website outside on your laptop with glare on the screen or you just had your eyes tested and they put the drops in your eye and you can't see very well so you know I think this visual really at one point or other in our lives applies to all of us motor in general it means that maybe you're not using a mouse or you have some sort of repetitive stress injury or you have limited range of motion right so again this can be more than just a disability where you can't use a mouse for whatever reason have to use some other assistive technology it can be that you are walking up to your front door with groceries in your arm or you're holding your child and you're trying to navigate or find some information on your phone with one hand your other hand is not available or you just forgot to bring your mouse and you need to navigate the site in other ways auditory so you can be completely deaf or hard-of-hearing or maybe you're just in a noisy environment or maybe you're sitting out in the conference before the session trying to watch a video like I was and you don't want everybody around you to hear what you're listening to so I just turned down the volume and it's kind of hard to see but this is captioned so I can take in the content and watch the video without annoying everybody around me on the train if I forgot my earphones or out in the hallway and cognitive again is a broad range it's the biggest category of disabilities it stains like learning disabilities in dyslexia this is the biggest group and sort of the ways that we make our website more understandable for people with these cognitive disabilities also makes it more understandable for everybody else so you make sure that the content stays on the screen for long enough for people to read it you make sure your website is organized and easy to understand manner you make sure that the content is is written so that it can be understood by a wide variety of people so well that makes it easier for people with these disabilities to access your content I'd argue that it also makes it easier for everybody else to access and understand your content and to use your website so I think this just highlights what I was saying is that designing for accessibility is not just designing for these 1 billion people who have some form disability is designing for all of us at different stages in our life making your web app more accessible by more people in more places so that your content can be used anywhere people are if they're holding their child or distracted or a noisy environment or low light conditions your content is still usable so it makes your website better it doesn't ruin it so a brief overview of the term section 508 and would K how many of you are already dealing with this by the way compliance or what tags compliance or no you have to listen you listen we have a lot of text on this slide so basically the section 508 was part of the Rehabilitation Act of 1973 and it says that people with disabilities have access to the same information technology as those without disabilities so there's all these standards that we have to follow when we're building the website which make your website better not work and but recently there is this thing called a refresh which incorporated this other standard so it brought 508 compliance in line with this other standard you might have heard of called Lake AG which is more of an international standard lots of people are using it it brings these two standards in line and makes the world less confusing we're not are we in the 508 bucket are we in the wood CAG bucket right we just meet the WIC AG guidelines and we're good to go so this refresh was published in January 2017 so just a few months ago and enforcement begins next year January 2018 quick overview of what these wit CAG guidelines are so it's organized under four principles the acronym poor is what you'll sometimes hear as a quick way to remember these perceivable perceivable operable understandable and robust so again I think if your website or your content is perceivable operable understandable and robust it's better for everybody so under those four principles there are 12 guidelines that you need to meet in order to be successful and those guidelines have three levels level a level double-a and triple-a and let's see what those mean on the next slide so level a is minimum set of accessibility so it doesn't mean that your site is accessible by a wide variety of people or that it meets all the guidelines that we would like it to meet Double A is a generally recognized guideline for web information and Triple A isn't really recommended because there are some barriers that make it more difficult to achieve success and let's look at an example of one of these so here is some great documentation actually usually these recommendation of these specs offs are really tough to understand and read but I find the wit tag documentation is actually really good so remember we said there are these four principles and these twelve guidelines so here is one guideline this is guideline 1.2 for time-based media you need to provide alternative and for meeting just the general double-a guideline which is recommended you want to have captions for your content and your live audio content to meet the Triple A guidelines might be a little hard to see in the back to me the Triple A guidelines you actually have to have sign language interpretation for all of your content which i think is a tougher barrier for most people for most organizations to meet is to actually get that content you know in sign language interpreted but for each of those guidelines on here it has information about what's required how to meet it and more details about understanding what this guideline actually means so I think that this doc if you haven't already checked it out is well worth your time so now I'm going to turn it over to tau for the technical details okay so so we have three main points for the knowledge and techniques how you make your website all web apps accessible the first one is focus so one is focus write focuses it simple definition focuses indicates which control and the screen currently receives your keyboard keyboard focus we usually quite focus ring it's kind of the visual indicator of which one which UI element on the page that received keyboard focus but I have a screen shot here the sign-in button there that's the blue outline that's a chrome default visual style but you could use CSS and to change the style so it's to bend down on it and then in other browsers like Internet Explorer Firefox may have a different focus screen so it kind of depends on the browser and your page style and another related concepts called tab order it shows when you use the tab key to navigate through the interactive elements on the page how their focus ring moves as you tap through so you can move backward or forward using a tab key and shift tab key so ladies interactive HTML elements should be focused both they should be the user should be to use the to be able to use the tab key to focus as their focus to those elements those are meant to include text field buttons links selector lists and some other elements normally they should not be focusable so paragraph a div span or H headings only the focus for elements need to support keyboard interaction so screen readers and the software assistive technology blind users or now five users are use they have ways to read focus ball and mount focusable element so I have a demo here sorry it opening a new tab so let me turn on the voiceover which is the screen reader is Mac OS it was overall drone now focus of illuminates window frame 0 has keyboard focus so enter URL requiring Lydia and it is so expensive use Patrick because the tech space will get focus okay then for the island and focus image I use a shorter voiceover quick key to navigate okay to not focus of limited exams oh do I have to go and you're heading level 3 to dress seven items bullets or even entire data so I can reuse this to read those non focus of energy okay - voiceover aw so the point here is you don't want to focus things that should not be focus because screen readers have other ways to to go to this element but you do need to focus interactive elements on the page okay so the tap water really matters so we catch one point three point two says that the navigation order the tabbing order should be logic and intuitive I think the thing is that sometimes we use CSS to alter the position of certain elements that may jump the tab order so you will see sometimes when you press the tab key the visual focus ring move from here and to here and then go back and forth that's really confusing for keyboard-only users because they don't know the natural order of the you the page and another thing is if certain elements are off-screen we should not set focus to those elements so one example is this calcite drawer pattern that we have sorry so some reason I can get out of the the full screen okay I'll do this okay but bunch of this but yeah so so by default the elements on the left ignore out of the screen so we should use the display lung or visibility hidden to hide those elements so those remains will not get keep or focus but once they are shown on the screen we should change back to say displayed equal block it will always ability but set to visible so then they can show the keyboard our focus ring so how do you test focus focus is probably the basic thing that we need to do to support keyboard users right so first thing is it's pretty simple everyone can do it tab through the page and see if the tap water is natural if the tablet is it really jump around on the page and then if you see its focus screens that focus rings that in the disappear you may set a focus to an element that is out of the screen so we should hide those focus screen for up stirring element and then you may need to rearrange content in the Dom just to make sure you have a natural tab order so if you you see this is really important if you use the SS to position elements so make sure you test that and make sure the tab order is still natural follow stage from top to bottom from left to right reading order so another topic related to the focus is sometimes you need a manager focus right so by default we usually set app indexing to zero so that means we need the thumbs natural order determine the tab order and then there's there's some cases that you need to set tablet or equal to negative one so you can use JavaScript to kind of control to move programmatically move the focus one example is like if you have an error message or a menu if the user you want to move the focus to those elements once that when they appear or if the user press the up and down arrow key to move in a menu you need a switch that happens index so it's kind of in line with the users interaction but the anti-pattern is you set tabindex to anything equal larger than one that's kind of the a dependent then because that will be the first thing the user tap into it it may easily jump out the Vltava order so make it confusing for a lot of users so one example here I know this is kind of another realistic example because you should publish you use input option but this here I have a custom menu right so I have menu item so that I initially actually the first item to the tabindex to equal to zero all the other items equal to negative one as I move the as I use the arrow key to move down up and down in the menu I programmatically set the one that is that has the keyboard focus to zero and the rest of them to the negative one so I can show you guys the example here so I have this is the HTML here on the left and on the right there's some JavaScript code that takes the the key key down pigment and then programmatically move the tab index a set of tabindex to zero for the next focus or menu item so first thing I'm on the map so if I move down to the layer you can see I change the focus and then because of the CSS I read they also get the as I move down up and down they also get the tabindex equal to zero for the current element and also the caramel at current element gets the focus indicator so another concept is called a keyboard chaps so you don't wanna in the certain page in a certain element on the page you don't want to check the keyboard focus so the keyboard users should be able to tap through the whole page without being trapped in one place of that page the only exception is when you have a modal dialog you want to keep the focus in the modal dialog when the user is working in that dialog and when the user dismisses the dialog you should return the keyboard focus back to the initial element that opens the dialog so one example here is this numbers pretty interesting is called incredible accessible modal window so if I move to the view the model window button and I click on it right opens the model and my focus is in the dialog as I tab through all this field and buttons once I close the dialog my focus returns back to the button that initiate the model dialog so the user can continue continue on on the page so this is really good practice for a lot of applications where you don't want to user tab to thing open the dialog finish the dialog and then they have to start from the top of the page so that's really a bad user experience for keyboard users so we talked about the focus and how you manage focus keyboards tap and then the second part of this is knowledge and technique is the semantic HTML so a concept that's really important is called accessibility so it's kind of imagined this is the tree that screen readers or other effective technology used to interpret the web content so it's like the screen readers Dom tree if you will so the browser will take the normal Dom tree and render the accessibility tree to the screen readers so it's each browsers responsibility to take what you have in your HTML and then render that make it available there's there's a bunch of accessibility API in each browser the screw reader use those API to read the sabitri from the browser so like for example some browsers even have this display so if you have Microsoft edge in the this button here the kind of the time clock button there it will show you the accessibility of the current page and you can see I have this application for each for the buttons for the links they will show the name of the element the state of the element and in chrome the developer version of Chrome you also have a accessory tree view next to the normal down review view okay so this screenshot shows the typical booking flight form so you have this radio button to select either one way to reprogram ship you have a name input and then you have a seat type drop-down box drop down at least and then you have a search button right this is how accessibility how browser interpret is form and then convey that information to screen readers so the browser will tell the screen reader hey this is the button it has a name called round trip and the state is selected I mean not an option input so the brought the the screen readers will read this and then come lay that information back to the real user so again so the also the screen reader will relay users input like mouse clicks or keyboard clicks back to the accessibility to the browser the browser will take that input and change the state of the page for the user so as developers we really need to express the semantics of the page correctly because if you do if we don't have good semantics the browser doesn't know what information it needs to come late to the screen reader and we need to have accessible names and descriptions because again those those information will be put into the accessibility for screen readers to use and we need to make sure important element have accessible Rose state and properties we to talk about in a moment so one thing one good thing is most HTML interacts elements have implicit semantics to their role and the state select button link select input those are natives of you have latex support so we should take advantage of this and then they also work across browsers so one example is I have a link so right so I just use the native a element and if I turn on the screen reader sorry and then go back we saw we look at that one have to that one Nancy F ok that one perhaps you had one perhaps you a free packet add 100 RS a belief that one a-two a-three padlet final low section stuff title exact add one bad one backstabber that's you let's not read that kids close to the lab son Max you there after II at once actually that one yeah okay at one pass you love three that one's actually have one so I'm trying to a inner pad one pad to after a bad one absolutely after 810 actually write a little section it working fine chemist on hallway this gremlins in the room voiceover okay HTML semantic example winter catwalk absolutely have reset a battery that one section sorry by that too after each have one section I think it's maybe because I'm in the fullscreen booth let me try again sorry how many of you here test it was a screen reader okay yes I don't know what half of the air but at one section a 2 a 3 at one section one pass you let me go back so that screen readers screen reading oh you did build functionality that's cool wishes we should talk sure - yeah but yeah basically the screen reader will read a role this is a link things we have text inside the a element it will read is this SV homepage link and it will say hey this is focusable you can say focus to this link and then another example is a checkbox right so a chat box has a native role called checkbox and then it has a name because I have text next to a checkbox and then have a state is it focusable it's a check a not check so the screen reader will actually read this and also show the text input the text display panel there so we talked about lady with HTML element that are inactive will receive keyboard focus so the link the button the input one thing I want to point out is the button need to support space key well so if you write a button if you use custom HTML make sure you need to receive make sure that button receives space key because in the lady of HTML specification space key can activate a button so links and input you can use click or Enter key to activate those elements so like I said some of the HTML elements will not have implicit semantics so elective or spare and sometimes we need to use this element to make interactive elements right so like buttons or menus things like that how do we connect those things accessible so first we need make things those things focusable so we need add tabindex equal to 0 to those elements right and then we need to write some JavaScript to make sure those element receive keyboard events like the space key the Enter key and then we give we need to give them a name either we use the text label next to those element or we use implicit text area label I really believe I will later and then some of the things will have different roles and they there are menu or alert message dialog or things in manager we should specify a role if whenever possible and then some other thing will may have different states like the checkbox checked unchecked for menu you will have expanded collapse those states should be also communicated to the screen reader so which brings the third part of this knowledge is the area areas called web accessibility initiative accessible rich internet applications it's a long name but but the reason we need area is first of all we should use native HTML elements whenever possible but certain semantics and interactions are not supported right now by a native HTML element for example a pop-up menu we don't have anything in HTML that says hey I can just read this this will be a pop-up menu we have to write things on our own the another example is that you have a learn message the user that needs to know that know about this as soon as possible maybe you have an internet connection break down or there's some changes in your data you need to communicate as soon as possible to the user it's easy for the site legal user because they can see your error message but for low vision user or now say the user there's issues write some custom HTML using the area attribute to communicate that information to now sighted users will have the demo of that in a moment but area is kind of the specification for increasing the accessibility of the custom elements it is well supported across all the major browsers so you shouldn't have any problem if you write area elements in your HTML and then it kind of a demented the Dom or the etc tree in your browser so maybe you're missing some of the rows or states but if you add area correct appropriate attributes or states in those elements the screen reader or the accessibility technology will get the full information from the accessibility tree so but area doesn't do anything about focus so you still have to take care of the tab index and then it doesn't support keyboard interactions you still need to write JavaScript to receive those keyboard events so still need to read in implement custom behaviors but area kind of is focused on the accessibility tree make sure the screen reader can still can get the full information as the normal user so there are three types of area attributes so we talked about the rows so the meaning of the element basically what is this thing the tooltip is the tablet research and then the property of the element is the second type so the relationship and functions is a for example you may have a field that is required it's easy to just have a star or next to the fuses or with your users they can say oh this is a required field but for non sighted users we need to use every required attribute to indicate that and then if you have that in that field then the screen reader will tell the user hey this is a required field and then states we talked about the checkbox checked uncheck state use area check to indicate that for the screen readers so one example is the this is the checkbox right I just read a li but I style it as a checkbox so go back to the code here I have the tab index so it can be focused I have a checked indicator so I will see the checkmark but for screen reader users there's no way for them to know this is the checkbox because they can see it right and then i am i use the li element instead of the checkbox element so the screen reader will still understand this as a li element so when I need to do here is I add a row I say even though this HTML is the Li element this actually its row is a checkbox I also add the area check for the checkbox state 6 - so screw rule now oh there's a checkbox and also it's checked let me show you the screen reader example hopefully this will work no but yeah okay that's a bummer but yeah but it was it this is a checkbox this is checked and then we'll read the text inside of it we'll figure out how this works after this presentation and then your any questions and just contact us and then we can show you the example here okay through the rows so landmarks so there are different are we define certain networks for the page so you can say this is the banner this is the content info this is the man this is a navigation and this will really help small readers to understand the page structure so one example here I hope this will work this is the artists on lines new item details page so we're kind of designing those pages to be accessible moving moving forward so let me turn on the screen readers okay this works so I the page has all those networks building so I can use ignore this voice so I can use the menu to jump to a particular section on the page - - this will make this screen reader user quickly to get to different parts of the page navigation search comes with new items in landmarks menu loading more items no I don't say landmarks menu then Coover this in practice I think there's something wrong with the keyboard okay let me turn it off okay there are some other rows like those are named Martha Rose are four pages right but if you write a widget like alert dialog or data grid or tab list those are for this those are rows as you can assign to those widgets and then this talked about a little bit about properties one of the like most Commons use property is called area label so like the hamburger menu right it doesn't have a text so for my the users the user one I know what this menu what this button is for so we need to add area labels say this is a menu and it will overwrite anything you have inside the button but since this is a graphic pattern it doesn't matter it's alright so the screen reader will read this menu from the area label and it will affect visual users it will affect normal users because normal users can still see this is a hamburger menu another example is called area labeled by so this is where you can specify another element in the Dom as the label for your element so the drinking option is in the span right I have a list of radio buttons and then can specify the list of radio buttons is labeled by the drinking drink options span I just need to specify the ID so the good thing about area labeled by it is you can use it for any element so not just buttons or links and then relationships area ons so for example for the reason you have this multiple label menu right and then one parent menu has a sub menu and then for some reason in the Dom you have to write them separately but you can use area tones to say hey for the new menu the document spreadsheet the presentation values is a sub menu of this a new menu so you can again use the ID to indicate the relationship and another one is called area described by so we already have the password as a label for the text input but also you have another Texas's about the rules of the password input so visually you can tell the semantic relationship between the input and the description right but for screen reader users will all land sighted users they don't know about this relationship so you have to use already described by to say the password must be at least 12 characters is the rule for the text input and then another relationship area label is called area controls so let's say if you have a custom scroll bar right a scroll bar controls the main structuring of the page you can use the area controls to say this scroll bar controls the main page for the screen readers to understand that relationship and then we talked about the height elements right so you should hide use the display equal lung always ability equal hidden to hide element there's some subtle difference there so the display lung will not allocate space and the visible healing will allocate the space for that element but this either way the element is hidden from the dom tree the extensibility that is also hidden from the accessibility through readers will now read the tournament so if you want to just hide something but you still want people screwing with your users to read those things you should not use this a CSS attribute and then on the other side you may want to show information only to screenreader users for example you may have a bar chart you may have a graph that visual users or sighted user can read it without problem but screen readers cannot read shapes or visual representations so you have provides we had you need to provide text with descriptions or maybe data tables but you don't want those data tables to affect your visual design so you can use this CSS class to hide that element but screen readers can still read those information and then you may wanna sometimes you may want to hide certain visual element this is where area hidden comes in handy so a demo here I wanna I will now use screen reader but here I have this github it's a fun fun icon you don't want a computer to read the phone icon because it has nothing in it right so you just say area he didn't equals two to hide the phone icon from a screen reader so screen will just read the text okay so the last part of this is called the semantic we talked about right that there's information that user need to know as quickly as possible so it's called area life and the the road that works with aerial life is called alert so I think the most reliable way to write this is you have a container already in a Dom has that has a row equal to a alert right and then when you have error message or things that you want user to know you just fill it in that container with the message and then area live has two types the Politis it will allow alert a user when the screen reader is available and then I realize equal to assertive it's like this is really important screen reader will stop what it's doing now and then just read that message for you so I don't know if I can demos do this for me to try it yeah okay to do a different machine yeah okay so I'm going to try it I'll probably have the same issues but let's see so we have a sample okay we have a sample app here we have aria-live enabled so just perfect organ space in 36 hours went to is open source panel sometimes you guys heard that so this map shows trails in I think Boulder Colorado and we have these buttons that allow people to filter by dog accessible handicap accessible horse trails so when excited user clicks the button they can see that the number of features on the map are less they can also read the text about 36 parks so what we did was we set up aria-live so that when they press that button it reads back that information right away and says hey 36 parks were selected that meet your criteria that's an example of reli but i think you go ahead and for then there because it's also sorry and you switch that it is it that time already no no do you have more yeah okay so some best practices which we talked about a little bit when we introduced different techniques here so first one is do not change ladies semantics I'm gonna so you really have to do that so for example you want to implement a heading which is also a button so don't do this put assign a role to put a button to the to edge to tag and then a better way of doing that is embed about an element inside edge too and then all the interactive area elements must be usable with the keyboard so one example is that if you have a button customers button you have a role or equal to button and you need add tabindex to zero and then you need to write some JavaScript to support the enter and the space actions so you see where I'm going with this right so if you write if you need a button just use the button element otherwise you have to do a lot of work the tabindex the focus the rows the people events just a lot of work right so it's not worth it so just use dative HTML elements whenever possible and then another thing is the user map the keyboard user must be able to get the same information as the mouse user so for example if you the mouse user can click through a data grid to read information in each of their to read information to each cell the keyboard user should be able to be able to use the tab key or arrow key to go into each cell and read that information and then the third row is and a lot of people I mean a lot of web apps we think they use Rho equal to presentation or error hidden equal to two visible element and focus for element this will really break the screen readers because it will read out people that when the screen reader focus on element will say nothing or screen the keyboard user will focus on element and then it doesn't do anything so if you have a button you really want user to use it don't use the Rho equal to presentation because the screen reader will not be able to use the button and then don't hide things if you want if you want users to use those things and then the fourth element is all the interactive elements need to have a label or name so one pattern we use an ESRI in our calcite web is we use label to kind of as a container for the input so this will give give us accessible label with the interactive element it also makes that when you click on the text they will focus the input so it's kind of extra benefit it's a nice thing to have okay okay now we're going to talk about creating accessible web components so there's this another nice document that worth reading on Aria design pattern so how mentioned earlier that there is no such thing what would the example you use a comma new pop-up menu in HTML there's no HTML pop-up menu element so you have to create your own and you're using games probably an other HTML elements and you need to assign these Aria roles to it so if you have to do it's worth coming to this documentation and checking it out I think it's really really useful let me go back up to the top okay so there is a list of all these different types of components that you might want to create so if you want to do a menu or a menu bar you can come here and it tells you some text about it it tells you the expected keyboard interaction that your menu bar should have so it provides lots of detail on how it should work and also I use this sometimes when I'm figuring out how to test these elements what the expected behavior is they also have examples some notes the required Aria role states and properties this is all information that's how I already told you about so we don't want to focus on this too long because the documentation is really good and really detailed and if you have to do one of these things just come here and check it out the next thing we want to talk about is the accessible map so this is tricky right map has all these features on it how do we make these Maps accessible I don't know that we'd have a super great answer but there are some some techniques you can use the first thing I think is to try and remember that the map contents need to be perceivable and understandable too so we have our app where's our park locator app where we created this symbology and these black black shapes and they look fine in the topographic base map but what if we have a base map toggle or base map gallery in our application and people switch to a different base map so here we have satellite imagery those black label or black marker symbols don't look so great anymore they're not really as perceivable the contrast ratio is probably not high enough and we might want to think about the different base maps that are offered and think of ways to deal with our symbology that's going to work well for the options that we provide so we'll also want to deal with scaling of images and texts for non tighted users you have some strategies like providing information in a table right they can access a table and browse the information in a table you can have alternative text in some cases that might be enough this app has five points on it that show these values right but in most cases that's not going to quite cut it so you probably want to provide people an alternate way to access that information Google Maps has an interesting example I think an interest of time we're not going to demo it but they just sort of overlay a grid over the map and you can navigate through by tabbing through the content and then select the features I think that works fine if you have a small number of features in your map in that extent that you're looking at but if you had a 180,000 points it's not going to be so so helpful but these slides are available afterwards you can come in and check out that documentation and check out that example so we're going to look at a demo we looked at it earlier with live REO but we're going to see that we have an example we put together that has some common accessibility issues so we'll look at these and and we'll look at briefly how you might find them in your app and fix them so I think we mentioned earlier when Tao was talking that you know one of the easiest tests you can do when you're testing for accessibility is to try and tab through your site so let's say I'm going to refresh my page let's say I come to this site the first thing I try and do is tab through it I can tell already I have a problem because the first tab I click it took me the third button in that list so that's telling me I probably already have an issue with my tab order I'm not following the natural Dom order I've got something funky going on that I'm going to need to investigate so I know that I have one problem and you can look at things like you know I mentioned earlier if we have this base map gallery is our contrast ratio good enough can we read this text you know is our website organized well there's also some tools that can be really helpful one of these that I use all the time is the developer tool so let's come here and go to the developer tools there's this extension that you can run call the axe accessibility checker by DQ awesome so I can just click on this button and analyze the page and it tells me where it's found the problems it tells me right away that I have some element that doesn't have sufficient contrast ratio so I can come here and inspect that particular element and I see okay my search parts label right here is a really light gray right I don't I don't have any necessarily huge vision problems but I can barely read that so I know that I have an accessibility problem and then Chrome has a nice tool that can help me figure out how to fix that accessibility problem so if I come here to accessibility properties I don't know it might be kind of small for you to read that text but under color it has a yellow exclamation point next to it it tells me a contrast ratio is only one point five one between the background color and the text color and excuse me the wit CAD guidelines so if I want to meet the double-a guideline I can use these colors and all be good or if I want to meet the Triple A guidelines I can use these other colors and I'll be good so I like that you can just click on it on the colors here and you can actually see it changes your text so you can see how it looks in your design right within that page so I use that tool a lot I'm not a designer so I like the cheat that they just tell me what colors I can use another problem is that it tells us that images must have alternate text so we can see right here that we have a problem we don't have alt text associated with this logo at the top of our page that's an easy fix we just add alt text right to our image so this one's a low-hanging accessibility for you can run this extension you can fix the easy problem and then it tells us that we have an element with the tab index is greater than zero so remember how I said be tabbed into the app and we ended up at the wrong place it's because for some reason here we've specified tabindex 3 on this button so we're taking it out of the natural tab order and saying this is the you know tab index 3 so it messes things up so we'll get rid of that get rid of that but then you know I'm wondering why this button didn't tab so let me inspect that and see what's going on I can see that right there I did something bad right instead of using a button for a button they use the div for a button and we can see that the other problems like it works it filters my map but there's no focus right now focus element that we get with a button so I would have to handle that I would have to specify a tabindex have to specify the focus I would have to specify the eye roll label and you know some keyboard navigation and that the house will just use a button one other thing that I wanted to show you here in sorry the chrome tools is there's an accessibility experiment that you can turn on the chrome developer tools if you go to the extensions in the settings there's an accessibility inspection tool I think you can turn on and that gives you access to this additional information so talked about the accessibility tree if you want to visualize this for an element you could click on the element and see the accessibility tree if we have one with Aria roles like this one or Aria attributes it tells me the Aria attributes associated with it and some additional information that can be useful so I like to keep these two two tabs on you go back to the slide yes okay so that's the end of our sample app it also use the surge so if you type in the search the search widget the JavaScript API is accessible if you enter the values extreme read or weed it you can search the results and act as a pop-up information but you can look at the demo it's in the slide later so the last little bit of information we want to talk about with automated testing there's a couple different options for doing automated testing of your site one of them is this Ali command-line tool by I do smonny he's a Google developer and this is no to install it through NPM no package manager and then you can audit a particular website so this example here shows the command a well my give the URL in this case pushing the results out to a text file so you can look at them later here's another example of the module usage of that ali extension another one is x at core so i use an ax extension in chrome this is ax core it's good for you to do automated except ability testing you install it with NPM install and then you include this script tag you include this script tag you can see it here pointing to the axe min jf and then you can run your functions to test various functionality there's good documentation on that on their website we have a lot of resources we showed you some of these already the yr8 way aria authoring practices the wood CAG helps we have some there's some courses that we think are useful if you're new to accessibility i like the web accessibility one by google is free it short can watch it at your desk I think we covered everything else there developer tools fundamentals so last seen is please take our survey we want to make this better if we present it again next year anything that you wish we told us in that we didn't or something that we did tell you and that you wished that we did not tell you let us know feedback is helpful now we'll make sure the next time the voiceover it works there's always something that doesn't work so the voiceover work something else won't work like the projector so so we have a few minutes for questions yeah yeah so in the Forex API has a team is working really hard to make the widget accessible and to think about accessibility principles when they're designing them if you notice problems let us know submit bugs but yeah so in the forex certain we display and measure and draw that kind of excessive a degree of acuity in interacting with the map I mean are there is making them making accessible exposition for resale well I think in general I think that those are tricky and that you may be able to just get exceptions for those as a general yeah I think the general exception is if you have if an interaction involves hand drawing freehand drawing those are exceptions and we can so you don't have to provide equivalent interaction or yes I think in the rules yeah we'll say especially freehand drawing like if you just move the cursor on the map to a thing or if you have to use a tool a line collect two elements those are exceptions that yes no way for you think keyboard only but it may be possible to provide the equivalent information using other means that you don't have to use the same element but that inquires additional UX design for those kind of things I definitely definitely good news but is a piece that simply that is really still that meaty hands I would say like you know that's a good question and I've asked about it I don't think that we I don't I don't think that we have one that existed explicitly defined as you know accessible but I mean and something definitely for us to to look at so yeah we are talking about this more and more and more on the on the team within ArcGIS online and the JavaScript API team so we're working hard to make improvements and we know that it's important to the user community so we're thinking but that's that's a great question I think I actually asked it a few months ago excellent question yeah I think and I think for for those kind of custom buttons we use the same principle to evaluate right so if it's focusable if you can use keyboard the Enter key or space space key to activate the button it has the accessible label I think that's good enough but we ran into some issues with some excerpt party UI libraries so I think safest approach may be a quicker approach is to use native elements for example tables you could have a table reason in depth right and then you suppose those focus keyboard focus you suppose this keyboard interaction but it's a lot of work to write a table custom table because HTML has a table element when I use the label one it may be quicker but I understand sometimes you have to use those things but then yes extra work and extra evaluation to do I wanted to just add one quick I don't work with jQuery I have not a long time so I don't know it's you know accessibility guidelines but dojo cares about accessibility and they do have a statement accessibility if you go to any of their widgets usually at the bottom of the page there's information on the accessibility of that widget so that doesn't mean that there aren't any problems in the end the widgets and some of them there are just like in some of ours there are but if there are you submit a bargain and let them know and ask them is fix it but they care about this issue and they're trying to ensure that their stuff is accessible so yeah I think a general trend for a special format online is moving forward we want to use a lot of later HTML elements just make the page cleaner and it's easier to to work with all the screen readers anybody else I will thanks for coming and we appreciate it [Applause]

Channel: Esri Events

Views: 13,961

Rating: 4.9354839 out of 5

Keywords: Esri, ArcGIS, GIS, Esri Events, web accessibility, WCAG, web components

Id: pSOMZjm_lco

Length: 57min 2sec (3422 seconds)

Published: Wed Mar 29 2017