I do not want to take more of Jared's time. He has got a lot of good material here so I'm going to drop off and Jared, you are the boss from here on out.
>> Okay thank you, Norm. I appreciate the introduction. And thank you all for being here. I know many or most of you are back from last week. Fortunately, no technical issues this week. I am able to hear everyone, so we will hope that that continues and we don't have any issues this week. I am Jared Smith from the web aim. Web aim stands for web accessibility and mind we do web-based consulting and we are based here at Utah State University in Utah. It's a beautiful day today and noon here. I appreciate all of you at your various times, I see Andrew at 4 AM from Australia. I appreciate you being here again this week. Today we are going to talk about advanced web accessibility evaluation. And also doing accessibility evaluation using wave. Last week was an overview and introduction to wave. I'm going to give a little bit more insight into evaluation methodologies and approaches and tools. And then toward the end, talk about how wave can facilitate accessibility evaluation.
Just a few things to set the framework, I hope and think much of this will be apparent and obvious to those of you who have done web accessibility work but it is important that we have a proper viewpoint of accessibility if we are going to properly evaluate accessibility. And accessibility is about the human experience and because of that only humans can adequately evaluate through accessibility. I know I said this last week, but it is just so important that we keep that in mind. That there is always accessibility point aspect and evaluation for everything if you are going to determine whether something is truly accessible to a human. There is no way that automated tools are systems or anything else can accurately tell you whether something is accessible.
Just to expand on that a little bit more, well, we have the viewpoint of accessibility being about a human experience, that also means that it really is a continuum. It means that you are never really fully done with accessibility. Any time someone comes to me and says my website is accessible it doesn't really mean a whole lot. You need to quantify that. Accessible to whom or accessible to what level.
So we do have measures along this continuum. We have accessibility guidelines and standards that we can become our sites can become conformant to or complaint two. That give us a measure of accessibility. But ultimately we are going to favor accessibility over complaints. These guidelines are wonderful. They help facilitate and support accessibility, but they do not insure it. So we are going to always focus on accessibility over complaints. That is not to denigrate the accessibility guidelines or suggest there is no value there. There is. They are wonderful. They can be really good but we need to think beyond treating accessibility as a checklist. If we meet these things, then we are automatically good, and it just does not work that way.
To take this a step further we also need to consider technical accessibility versus functional accessibility. So, technical accessibility is implementing technical implementation. Proper code, markup, following standards, checking off all the boxes to make sure you've implemented things in a technical way so that something is technically accessible. That is wonderful, but again it also does not ensure a positive user experience. It does not ensure that the functional experience of a human is always going to be optimal or friendly or efficient.
A good example we use of this technical accessibility versus functional accessibility is website navigation. If you consider many or most, maybe most websites that are out there, maybe your own website probably has navigation elements across the top and at the beginning of the webpage. How many navigation elements are there from the very beginning of the webpage to the main content area of the page. You probably need to navigate through the logo, maybe search, main navigation links. He might be a few of those. There might be hundreds of those especially with a complex drop down or fly out type navigation system. There might be a sidebar. That contains numerous links. All would need to be navigated before you get to the main content area.
So, you can technically make all of those links accessible. But functionally is a keyboard user going to navigate through dozens or maybe hundreds of navigation links on every single page before they get to the main content. Probably not. So it is easy if we view simply a technical implementation of accessibility it's easy to say that it's accessible. It's technically accessible. Someone using the keyboard can navigate through the navigation and get to the main content on every page. But functionally it's not a friendly experience. It's not efficient. It's just, your users are probably going to disengage.
So, while many tools and really all tools focus on the first aspect, it's really focused on technical accessibility. Guidelines focus on technical accessibility, we need to look beyond that and focus on the user experience and functional accessibility.
So I'm going to present what we might call a web accessibility methodology. Or at least a bunch of things to consider in accessibility testing. And evaluation. This is not like a list of things you do in a particular order. There are a bunch of things to consider in your testing. One is to use a checklist. I just got done saying and highlighting the limitations of technical accessibility and focusing only on the guidelines as a measure of accessibility. But checklists and guidelines and standards are really informative to accessibility. A checklist can help ensure that you haven't missed something important in your accessibility evaluation.
So, you know you would want to define a good standard. There is Section 508 that may be a requirement for some people. That would be a very minimal standard. And maybe a place to start for a minimal aspect of accessibility. Section 508 is a very minimal standard so we would certainly recommend going beyond that to at least look at 2.0, the web content accessibility guidelines version 2.0. Much more up-to-date. You may also define your own customized checklist that has your own aspects of accessibility. We use a customized checklist. It has aspects of WC AG 2.0, and other things we know can impact accessibility but other things that might not be addressed in this particular guidelines.
And we have versions of checklists for these.On the web payment site. We have a Section 508 checklist, a WC AG 2.0 checklist, what we have done with that 2.0 checklist is we have taken hundreds and hundreds of pages of WC three material and the guidelines themselves that can be a little difficult to understand and to implement and we have boiled down to about six printed pages. And really high-level things, you really need to consider to both implement and evaluate WC AG performance. So it could be a great resource for you. It could be one of many checklists out there for WC AG 2.0 but we've tried to make it simple very plain language and provide links to a lot of resources and materials. Links to the guidelines themselves, the WC three just as a way to help you evaluate accessibility to those particular standards. So checklists are a great thing. They help to ensure that you have not missed anything really important.
One example of that might be document language. That is a WC AG 2.01 a requirement to identify the document language. Very often in the testing if you are testing in English webpage and you speak and understand English and you are using an English operating system and browser you likely would not detect that the document language has been not identified or worse, misidentified, the language of the document identified as a language different from what it actually is. A checklist can help you identify that. Simply going through and say I need to check document language view the source code, and check that the language is correct. These tests are often overlooked if you don't have a checklist to help you go through.
It is important to know the limitations of guidelines. If you look at WC AG 2.0 which is really the best set of guidelines I think we have right now as far as formalized internationally recognized guidelines they are very subject to interpretation despite [inaudible] reference otherwise there is interpretation. That's great if we are focusing on the end-user experience that allows us to focus on things providing things that will be useful to our users as opposed to a rigid structure that expects all to conform to the structure. [inaudible] There are some other terms that are just a little difficult to understand unless you really delve into the documentation for WC AG. So at first glance for someone coming to the guidelines initially it can be really overwhelming and very confusing for users. They are not comprehensive. I think I've said that in several ways already. There are many types of disabilities that are not directly or at least very well addressed by accessibility guidelines. Cognitive and learning disabilities is probably the most significant there, being the largest disability group that has probably the least attention in the accessibility guidelines. It is not because the WC three is not interested in cognitive accessibility. It's because accessibility for those users is really difficult. It is hard to define and there hasn't been a lot of research and work done there. The WC three and others are doing at and will hopefully be addressing some aspects of cognitive and learning disability accessibility in future versions of WC AG. That's not to say there is not anything there there's just not a lot there to help cognitive accessibility.
Guidelines take a long time to implement. To roll out. And they do not, they are not updated very often so they tend to lag behind technology innovation. Section 508 was finalized in 2001. WC AG 2.0 was finalized in 2008. You know, it is starting to show its age even WC AG 2.0 a little bit. While it was structured to have a long shelf like and it has. It has held up pretty well there are certainly areas of WC AG 2.0 that are not as applicable or relevant to some modern technologies.
Section 508 has been in the process of being updatedfor longer than it has not been in the process of being updated. You know, the current updates to Section 508 were started in 2006 and it is 2016. It's been 10 years in process of being updated. So it's hard to know when that will happen. We do very little Section 508 work here at web aim. Someone asked us, you know comes to us and says I need 508 compliance can you help us. Yeah sure, but we are going to go beyond section 508 because of its data, and because of the fact that updates to 508 well, let me back up a little bit. If you need to WC AG to point A and AA you will have met the requirements of Section 508 for future Section 508, so we recommend WC AG 2.0. And that's what you should be focusing on.
You also want to check keyboard accessibility. The significance and prevalence of people with accessibility issues has really significantly increased in recent years. It is quite alarming to us here at web aim just how much keyboard accessibility has become broken on the web. You know, if you would have asked me 10 years ago something that I thought we would have had figured out by 2016 I probably would have told you keyboard accessibility. But it is certainly not the case especially with complex web applications.
So keyboard accessibility is just so critical. Because it impacts so many users. Screen reader users primarily will be using the keyboard. Other users with motor disabilities, really any user can benefit from having a good accessible keyboard experience.
So really, really important. Fortunately, it is pretty easy to test this. Put your mouse away, navigate the site using only the keyboard. Ensure that all the functionality available to amounts user is available via the keyboard. Make sure that that experience is efficient and friendly. That can be facilitated with a skip to main content link if your site has navigation at the top, that link would facilitate or allow the user to skip over that navigation and jump directly to the main content. So, if your site needs one make sure it's available. Make sure it works and functions correctly. Very often those links are hidden. You know, with the idea that because they are fairly intrusive to visual design and really because [inaudible] links are kind of a hack they are a hack. There's no other way to put it. They are a bit of a necessity because of poor keyboard accessibility primarily in standard browsers you want to make sure they work. Sometimes they are hidden by default you want to make sure it becomes visible when it receives keyboard focus. Skip links are primarily, at least they provide the most utility and usefulness for sighted keyboard users. Those are the, users that would benefit most for them. Make sure there's a visible focus navigator if you're using a tablet to navigate through visual form controls that you can tell visually where you are at on the page so you know what things can be activated at that point in time.
You want to make sure that the navigation order is logical and intuitive. That usually means that it follows the visual flow through the page, left to right, top to bottom through the element of the page. If the navigation order is jumping around, that can be confusing for a sighted keyboard user only. It can create a disjointed experience between sighted users and screen reader uses that is navigating the page. It also creates a different expense for a screen reader user reading through the page and navigating through the page. That experience can be different so we want to make sure it's logical and friendly for the user.
With more complex web content and application it is important that you test keyboard accessibility with a screen reader running and without a screen reader running. With kind of more complex ways of building accessibility into complex widgets and controls in a webpage things can just function differently when a screen reader is running. At least a Windows screen reader because of the way that it handles interaction with the keyboard.
Andrew has the comment I distinguish between screen reader users and keyboard only users and have really trouble finding people in the latter category. That is a comment that you hear a lot. You know, I'm sure I probably said this keyboard only users. You know, the reality is that there are not too many users that can't use a mouse, that are only using the keyboard for navigation. They are generally using some other type of interaction to navigate with the webpage. It might be mouse keys where they use the keyboard to simulate a mouse. They may be using voice control or some other method to interact with the page as opposed to only the keyboard. So that is true. There are, I don't know. It's hard to quantify how many people would be only using the keyboard. Regardless of that, the aspects of keyboard accessibility are going to be important for the users that choose to navigate that way, or at least to give them the option of navigating that way. And I think that if we had better keyboard accessibility, and if browsers supported it better especially things like navigating by headings within webpage and navigating by landmarks or regions within a webpage and provided that functionality for all users that would be incredibly beneficial. I would love the ability, even though I have vision, I can use a mouse, I would love the ability to navigate using headings and landmarks. Within a webpage. I would love to S to jump to search, M to jump to mange, number keys to navigate through the heading levels on a web levels I would use the heck out of that functionality. So yes, you know anyway that is a common I think a misconception that the only user keyboard it tends to use the keyboard and other things. It doesn't mean that we should neglect however keyboard accessibility because it is important for many users.
So, navigating with the keyboard is fairly straightforward. Use the tab to navigate through links and form controls. Shift tab to navigate backwards. If you are on a Mac there is a setting in the application or system settings under keyboard. You want to enable full keyboard access. That will allow the tab to navigate through all interactive elements within the page. Shift tab will navigate backwards. Through Lance and form controls. The enter or return key to activate a link or button, or control the currently has keyboard focus, the is used to activate, to check or uncheck checkboxes. It can also be used to activate buttons. That's really important. A trend we are seeing a lot on the web is this misuse of buttons and links. That will typically take you to another webpage or another place within a webpage, buttons either submit form information or [inaudible] incorrectly so if you are using a link the markup is identifying a link, but visually it is being presented as a button or function of the link is to do button type stuff. The user may actually try to hit the two activate a button but it is, if it is a link that does not work. So, use the correct element for the right type of function that you are performing.
The arrow keys, up down left raider used to manipulate radio buttons to choose the selected radio button from a set of radio buttons. Used to navigate through select or drop-down menus and then more complex like sliders, tab panels, auto complete, tree menus you know, application menus, things like that my you can use the arrow keys to navigate within those. The escape key is typically used to close dialogues were menus or pop-up windows. Those are the basic keyboard commands. There are certainly more but those are the things generally that you want to use to test within a page.
There was a great comment about senior population or those that have temporary disabilities, surgery, things like that. Yes that may be using the keyboard. They may not rely on that wholly or entirely but maybe temporarily they might be using that.
Okay. Another thing you want to do is check your alternative text. Two keywords that we recommend when checking alternative text are content and function. What is the content of the page, or content of the image, and what is the function? If it does have a function what is the function of the image. That's what you want to convey in your alternative text. Very often alternative text becomes descriptive. What does the image look like? And very often that's not as helpful as focusing on content and function of that image. You want to check to make sure the alternative text is the sink. Yet also accurate and equivalent of the content or function of that image and there is a trade-off and subjectivity there. We tend to generally efficiency is really important especially things like web applications or pages that a user may visit many times. So, being insistent is important but we want to make sure that we are actively conveying the content of an image.
Does it make sense in its context? I think sometimes we lose track of that. We look at an image in isolation and try to determine what appropriate alternative text is. It is important that that alternative text, that we understand that the alternative text will be read in a broader context. Does it make sense in the contacts at the point at which it is read by a screen reader. That is one thing that wave does. Because wave does not remove the image, does not analyze the alternative text in isolation, it shows you the alternative text in the context of the greater, the broader page and allows you to better determine whether the alternative text is appropriate in that context.
You want to ensure that all functional elements have proper alternative text. So remember content and function, if the image has a function it must have alternative text. So linked images, buttons, image hotspots. Anything that has a function must have alternative text. And there's a lot of intricacies and nuance and subjectivity to proper alternative text. We have a detailed article on the web aim site about alternative text that can provide some additional insight into that.
Kim has a question is there a recommended character count to try and not exceed for alternative text. You know, I hate defining those kinds of things because it really varies. The vast majority of images on the web, the alternative text would be one or two words, may be a few words. That is, most images it would be very succinct. Occasionally a short sentence or two, very rarely maybe a few sentences. Anything more than that generally the content is so complex that usually it should be conveyed some other way. Maybe it's a long description page or maybe in the context of the image, maybe a data table or something below that image. Yet, Andrew says as long as it needs to be. And no longer is a good way to do it. One good question that you can often ask when it comes to alternative text is, if I could not use this image what text what I put in its place. Very often. That will help guide you to alternative text. So, technically there actually is not a limit. One time as an experiment I took the US Declaration of Independence and I cannot run for the character count, it was like 20,000 characters or something like that and I pasted it into a document like 5000 times. And I started jaws reading at its fastest reading pace. On the page, and I left it overnight and when I came back the next day it was still reading. So there is not, at least for modern browsers there doesn't seem to be a technical limitation there. You would not want to do that. It was just a bit of an experiment to see. Andrew asks what is your position on the long desc debate. Long desc is an attribute for an image that allows you to reference another page. That contains the long description. Let's say you have a complex chart or graph. It is a way to reference in the code that there is another page that contains the description for the image.
The difficulty with long desc is that it really is screenreader specific. There is not a way for sighted users to be able to view, easily detected that an image has a long description. So, what we usually don't advise long desc, or at least not relying on long desc as a way to identify that an image has a long description. What we would recommend for that complex chart or graph to provide a link because it's accessible to everyone to the long description page. If you also want to provide the long desc attribute and reference that you can and then it becomes maybe a little redundant. Is screenreader user would be identified twice that that happens, that the long desc is there. We feel that it's a little bit more universally accessible for all users which, anybody can benefit from the long description for a complex image.
Okay, moving on. You want to check your colors and contrast. There are two aspects to this. And they are very often conflated and mixed up and put together into one, but there are two things that we do need to treat distinctly. One is that we need to ensure that color is not used alone to convey information or meeting. And two, we need to ensure there is sufficient contrast. If you are checking contrast, the Web content accessibility guidelines have a formula that generates a contrast ratio and then they have thresholds to determine whether you pass or fail at certain aspects of WC AG and certain sizes of text. We don't want to do with that too much, we recommend using a color contrast tool such as the web aim contrast checker tool we have it on our website. You can put in a foreground color and background color. It will generate the contrast ratio. It will tell you whether it passes or fails. The WC AG requirements for various types of text at AA and AAA. So use tools to help you with this.
If you are dealing with say, images with text in the images or text on top of images you can use the color Zila tool to pull out the color values. Wave can also analyze the page and quickly tell you whether there are contrast failures. I will show you that in a couple minutes. There's a pretty neat tool called no coffee. No coffee. It is an extension for chrome. It's kind of an interesting name. But it allows you to simulate colorblindness and other types of visual disabilities. It can be helpful maybe not so much for evaluating potential accessibility issues but at least for experiencing and viewing your page as it would be viewed by users with various types of visual disabilities.
You want to check color reliance and make sure you are not using color is the only way of conveying meaning. One way to do that is to desaturate or grayscale the page, so remove the color from the page. There are some tools that can do that. I will show you how to do it in wave. You can also print on a grayscale printer. There's a great way to check contrast and color reliance. Keep in mind to treat these things distinctly. Sometimes we hear people say things like you cannot use red, you shouldn't use green because those are bad for accessibility and that's not really the case if you follow the two guidelines. If there is sufficient contrast and you are not relying on those colors to convey information or meaning.
You want to check in a screenreader. So, fire up a screenreader. Focus on the navigation forms, document structure especially for more complex things, make sure those are working correctly. We recommend when you are testing with the screenreader to not use the mouse, put the mouse away and try to use the keyboard. That's primarily was going to be used by screenreader users for navigation and input. Don't look at the page. Try to only look at it. Sometimes you actually hear what you see. Not what is actually read to you by a screenreader. So it is best to try to simulate the actual experience of a screenreader user. Do not worry about screenreader pronunciation. They tend to pronounce things the way that they do it's not always accurate and if you are not a frequent screenreader user that can be a little jarring. And potentially confusing. You may have this sense that you need to fix or hack the screenreader to make it read things in a particular way. For the most part don't worry about it. There's very little you can do about it and any solution you would try to implement to fix screenreader pronunciation would generally be worse. It would create something that is pretty complex. May not work all the time, and that actually creates an experience that is not typical for a screenreader user. Screen readers are really complex. They are heavy duty software that can be a little bit buggy and frustrating to use but it does not take a whole lot for most anyone to go in and do basic screenreader testing on their page. At least listening to the contents on the webpage and navigating through a webpage to make sure that all interactive elements are accessible.
We have tutorials on the web aim.org site for JAWS, and BDA, and voiceover to get you started with evaluation and testing using those three common screen readers.
Okay now to automated tools. There are a lot of them out there. They are all different and they all use a slightly different philosophy. Just a few things about automated tools. Just know that these types, especially sitewide auditing tools for accessibility are best implemented later in and accessibility process. We have seen people who have spent a lot of money we are talking six and seven figures here on accessibility auditing tools. Just to learn that they have lots and lots of accessibility issues. When good accessibility implementation and remediation efforts would have fixed a lot of those accessibility issues instead of spending the money on a tool so tools cannot replace good education. People can evaluate accessibility. They can however facilitate the evaluation.
So now taking a lot of this that we have talked about and bringing it back into the wave tool. Wave, I'm just going to do a really quick introduction. I know we did this last week but if anybody was not here it is a free tool that is available email@example.com. We have a chrome extension for chrome browser that performs the evaluation within the browser itself. There is a Firefox extension that we are hoping to work on we hope to release soon, there's also API that allows you to evaluate a page and get back data about the accessibility of the page and there is a subscription API on the wave website you can pay money and evaluate pages and get the data. Or we have a self-hosted or standalone API that we will be releasing freely in the near future.
So, wave, when you analyze a webpage it will take the original page and inject icons and indicators into the page to provide feedback about accessibility. It also generates a sidebar on the left-hand side of the page that allows you to see an overview of the accessibility and also to manipulate and interact with that page and the icons within the page to allow you to explore accessibility even further. The approach of wave is to facilitate human evaluation. It is one page at a time. It is getting deep into the guts and underlying code and semantics and markup of the page. To reveal that accessibility or potential accessibility issue to the evaluator so they can better evaluate it for accessibility. So, this is a screenshot of the Whitehouse.gov website. On the right it shows the original page. There are these icons that have been placed within the page to give feedback about accessibility. If you see text in a green box that is wave generated text. In this case there is the Whitehouse logo and adjacent to it is an icon that says alt, and it has a little mouse cursor icon on it. It indicates it is a linked image with alternative text and it displays the text of home. Home is the alternative text for the image. So this allows you to see that this image has alternative text and see what the alternative text is in context of the image itself. So you can determine, is home appropriate alternative text for that image.
Green icons indicate features, yellow icons indicate alerts, things you should take a closer look at, read icons indicate accessibility errors, things that we almost are certain will have a negative impact on accessibility and that you should be testing.
In the sidebar we have three primary views, this style view, which shows the styled original page, selecting those styles will disable the visual styles of the page and will show you the underlying structure and markup, and will also show you the underlying reading and navigation order of the page so you can determine whether it is appropriate. Then there is a contrast view that allows you to just look only at the color contrast issues within the page.
That's a really brief overview. We are going to go a little bit more into depth of some of the aspects of how you can use wave to better evaluate accessibility.
So, there are many icons. I talked about errors, alerts and features. There's also blue icons for structural elements. Things like tables, table headers, headings, lists, eye frames are all identified. There are purple icons for HTML 5 and aria, so things like headers and navigation, main content, footer, search, landmark, HTML 5, multimedia video and audio elements, aria is identified. Aria labeling is identified distinctly within the page so you can go in and evaluate those. So a whole bunch of things that wave can evaluate and give feedback about the accessibility or potential accessibility of that page. So, a lot of logic, a lot of things that wave is looking at within your page and then revealing to you so you can better test it.
For any of the icons that appear you can click on them and wave will display it a tooltip. It will give you a little bit more information about that icon. So, in this case, in this screenshot I have clicked on a green icon and the tooltip indicates that this is a skip link target. It is a target for a skip link. You can click on more information or there's a documentation panel in the sidebar and it will give more details about what that particular thing means. Why it matters, what the impact is on the user, how to fi fix it so that to make sure it's and plummeted correctly, the algorithm is using to determine what's in the page that causes particular icon to appear here. And any relevant Section 508 or WC AG 2.0 standards and guidelines. So, we have really structured wave to be informative, to be educational. So you can go through to understand what skip links are, wave identify them. You can click on an icon and it will tell you what that thing is and the impact on accessibility and what if anything you need to do about it to ensure that it is optimally accessible. That is all done right through the interface itself.
There is, the details panel on the sidebar allows you to really look at individual instances of things that wave has identified you know, errors, features, alerts and so forth. If you go to the that wave has identified of contrast errors. If you click on a particular icon, contrast icon either in the sidebar or in the page itself it will populate the contrast tools in the sidebar. It will tell you the foreground and background color. It will tell you the WC AG contrast ratio and whether it passes or fails AA or AAA for normal text or large text. These are the thresholds that are defined in the guidelines themselves.
So you know, really pretty complex contrast testing that is here.
Another thing that I want to also point out that our option in here for lighter or darker,, the lighter to click those in they will actually click those and change the value in the sidebar. Let's say you have a color combination that doesn't provide sufficient contrast it's a WC AG failure. You can click on darker on the foreground color and it will change the color value until you find a color value that does pass. You can then maybe implement that color in your page. So it is just another little feature that we built into wave to help you not only find contrast issues but potentially fix the contrast issues by finding A color that does work better.
At the bottom there's also a desaturate, it will change the color to grayscale and that can be a useful test for checking color reliance. Is there any color in the page that is being used to convey information or meaning. Selecting desaturate page will remove all of the colors so you can see if something has been lost because of that.
There is the outline panel. The outline panel shows you the heading structure of the document. All that you see is the heading in isolation. So you can do a few things here. One is, you can determine if the heading text is appropriate. Whether the things that are identified as headings are actually functioning as headings. You know they describe a section of content. You can also determine if the heading structure is appropriate. Is the heading level appropriate for particular element on the page. So what is a first level heading. What are subheadings below those. What are subheadings below those headings which would be H3 and so forth. That can all be accomplished in the outline panel. We also have a code panel at the bottom of the page. The code panel, if you activate it, it pops up from the bottom of the page and it will show you the underlying code of the webpage. And of their respective icons that are relevant to those particular elements within the page. So there is an interaction now between the page itself and the icons within the page, the code panel that will show the code that has generated the content in the page and the icons related to those elements and in the sidebar.
So code if you are more technical allows you to get into the guts of the page and the underlying code and see what potential accessibility issues might be. This particular screenshot shows a few things. It is an email address field where the user would type in an email address and there are two icons within the pages that have been injected. One yellow icon is for a labeled... I'm sorry, an orphaned form label. It's an alert icon that is yellow and if you were to click on it, it gives you the information. It says hey here is a label that is not associated to any form control. Wave is smart enough to identify that. That very often would indicate an accessibility issue just that would be very often that you would have a label identified that isn't associated to a form control. It would not really serve any function. So it may suggest that maybe the label used to be associated to a control but no longer is. So it is an alert icon. We draw that to your attention so you can look for yourself to determine whether it should be a label or if it is a properly, if it is a label whether it's properly associated. So that shows adjacent to the email address text in the page.
We then, next to the text box for email address there is a red icon that indicates an unlabeled form control. So, this really, even visually verifies hey, there is something wrong here. We have a label that is not associated to a control and here we have a control, text box that has no label. Something has gone amiss. The label text is no longer properly associated to the text box itself. By then going into the code panel, and if we look at the code we can see the label element, and don't worry about it if you don't understand the code, don't worry about this too much. It has a four attribute of email address and the input itself has an idea of email address with no – and an uppercase A, so there is a mismatch of the label four attribute and the input ID. Because of the mismatch, the label he is not working correctly.
You couldn't really tell that simply by looking at the page. Wave has helped to address that. Helped to identify that. You can go into the markup of the page, fix that mismatch in your code, and it would then be properly labeled. Once you do that, rerun wave. You would then see a green icon that indicates this email address field is properly labeled.
Andrew has a question of, do you indicate duplicate IDs. Kind of. Our approach with wave is to really only focus on accessibility issues. So we do not identify all duplicate IDs. That are present in a page, we do however identify any labels that are associated to multiple controls. So for instance if you had label for equals email address and you had two inputs on the page that had that idea of email address we do flagged that as an issue. So, yes we do indicate duplicate IDs, but we try to only indicate them in instances where that duplicate ID would negatively impact accessibility. Hopefully that made sense. Just because they are duplicate IDs in the page doesn't mean there's an accessibility issue. It's only an issue if it causes accessibility issues so that's what we focus on rather than, we don't want to flag things as errors that do not impact accessibility. Now technically duplicate IDs would be AW CAG failure, but there are many aspects that could be a W CAG failure that do not impact accessibility. Wave just does not go there. We focus on the end-user experience. Great question, by the way.
Just a few words. So that is, I think good to highlight the ways that you can use wave to really delve into the page and start to analyze it really in depth. It's just one aspect of testing but we hope it is useful. We try to make it very powerful. The real power of wave is in page by page evaluation. Looking at one particular page and digging really deep into it to identify any accessibility issues. The underlying analysis of the page, the thing, the brains of wave that have determined whether particular icons should appear within the page is pretty smart. And we have people that are only interested in that data. They want to analyze a lot of pages using this underlying logic to determine how accessible they are or at least are there apparent accessibility issues or things they should be looking at. Because of that reason we have created this API. API is an application programming interface. Think of it as like a plug that you can plug into the brains of wave and get data back without all the extra stuff with a complex interface. For a program to interface to the underlying wave engine.
So the idea with a wave API you submit a URL to the API, the page is evaluated on our server or your server if you have installed the API locally in the server returns to you structured data in either J sans or XML format. Those are just ways of packaging data in a nice way so you can analyze it and break it apart and do all sorts of fancy things with that data. It returns the data about the accessibility of the page. So really what happens is if you have any, let me back up, any icon that appears visually within the page will be returned as a data point by the API. When you get that data you can do whatever you want with it. You can put it into a spreadsheet, you can email it out, you can put it into some sort of analytics engine, you can look for changes over time you know, you can put it into a bug tracking engine, whatever you want to do, that is the power of an API. We don't constrain you with an interface, or particular ways to use that. We just provide you the data. The visual interface of wave, if you go to wave.webaim.Oregon and you put in a website address, what you see visually is an interface for the API. It is just a fancy interface that utilizes our API on the background, in the background to present a visual presentation of that data. You don't have to do, you can build your own interface you can do what you want with that particular data using the API. So what you see on the page is an example of the type of data you would get back. This shows you what it looks like within a web browser. You probably would not use the API within the web browser. You don't want to really see the data. The API is typically used with some other program or an application to analyze that data and do things, whatever you want to do with that particular data. So there are three levels of output for the API.
The first level, we will just show you the number of items in each category. So errors, features, alerts, structural elements, HTML 5 and contrast. It will tell you how many of each of those appear. So the screenshot is this first level. It says, it has structured data about the page itself and it says there is one alert. If you get into it, there's one contrast error, there are zero errors and features that kind of thing, that the first level of output. The second is that plus the number of each issue type. So at level II it might say there are 27 errors and there are 10 instances of images missing alt text. There are five instances of linked images missing alt text. There are two cases of a broken skip link, three instances of form controls that are not labeled. That type of thing, so you can really get into that level of detail and of the third level is both of those put together plus the X path. The X path is a way of tying a particular item back to an element within a page. So it is a complex kind of programmatic way of saying for instance, this image with alternative text is this image within the page. And it is a way of identifying uniquely every element within the page and tying the wave error to that particular element. Don't worry about too much, that would be for complex interfaces such as the wave website that uses X path to ensure that a particular icon appears with a particular element within the page.
So, Andrew has…we are at time that went really fast. Andrew has a question. I'm going to go to the next light here and please post them into the chat window. Andrew asks let me see if I can explain this meaningfully. I have a page with a form after I put a keyword into the edit field the page changes if I runway began ash them it will check the page as it now stands. Yes if you are using the extension because the extension works within the browser itself. If you manipulate that page itself you know, putting the word into the edit field it is one instance, more complex interactions things like opening the dialogue window, loading dynamic content into that page otherwise if you are manipulating or changing the content in the extension or in the browser when you hit the extension icon it will then evaluate the patient's current state. So yes that is the case with the extension.
With API or the online version of wave it will evaluate the initial state of that page. What the accessibility is when the page is loaded. So the extension does provide that additional functionality. You can, using the API, you can use other tools to do that type of thing. You actually can manipulate page content and get the page to a particular state and send it to the API for evaluation. A little more complex.
Well, thank you. I have not seen any other questions come in and we are just one minute over time. Thank you for your time today and thank you again, Norm for the invitation.
>> I want to thank Mary for doing the captioning. And probably see you for another webinar in September. I want to thank everybody for coming and obviously a lot of work has gone into creating this tool and it's very thoughtful and I'm impressed and glad that we could demonstrate it to you and obviously Jared is as good a presenter as we can find, so thank you Jared. And Beth and I will probably see you in November. Thank you everyone.