I'm Jared Smith from Web Aim. Web aim is the web accessibility and mind project. We are based at the centers for persons with disabilities at Utah State University and I appreciate the invitation from Norm and EASI and the group they are to have me back for another webinar to talk about wave. It's been a few years. It is nice to be back.

So we are going to talk about wave today. We have a pretty small group so if you do have any questions please just post them up into the chat window. I may not be able to hear if they come through via voice. For some reason. But please just post those up into the chat window and I will address any questions as they come in. Today is going to be a bit of an introduction into wave and just getting started using wave for accessibility evaluation. Next week we will be more in-depth in the evaluation in using wave and some of the related tools with wave to perform a little more in depth evaluation and testing and really getting into the guts and the detail of wave and how it can help you with website accessibility evaluation.

So a few details about wave. It is web accessibility evaluation tool. And it is a tool that we develop here at web aim and provide freely to the community. We really maintain and build this at our own expense and sometimes notable expense. In some ways we build wave for us. At web aim we provide web accessibility consultation. We provide training and a big part of what we do is website evaluations. We will evaluate the website and document accessibility issues.

 So we did build wave to help support our methodologies and approach to website evaluation. And so we build it to think the way that we think in the services that we provide and then we just give it away to everyone free and we hope it is of value to people. We hope that it is. We believe that it is. Last year the wave website was used to evaluate almost 1,000,000 1/2 webpages. So I think that is incredible. To us it really makes the investment that we put into wave it worth it. Knowing that 1,000,000 1/2 webpages were evaluated by thousands of different users and thus just the online. I will talk a little bit about later about the extension we have and at best guess, we don't have exact numbers on it, but at best guess the tool is used to evaluate maybe 10 times that many webpages it's a little bit difficult to know.

 There is a comment there, which slide are you on, hopefully you are seeing this lifetime now moving onto slide number three. Maybe I will pause for just a second and see if you are able to actually, if you are following and seeing the slides that I'm seeing, if you are able to confirm that.

Beth is able to confirm this slide says no automated tool can tell you if your site is available. Accessible. Accessibility is about the human experience. It's about people. And we use tools and we use guidelines and standards to help facilitate accessibility to help support what is happening for the end-user but hopefully accessibility is about that human experience. And as such no automated tool, no computer-based system can really give you a good indication as to whether the end-user human experience is accessible or positive or efficient or really anything else. There's always going to be a necessity for human evaluation. That the only way you can actually evaluate whether there is a good and accessible human experience on the other end.

Moving to the next slide it sounds like some may not be seeing the attached slides as I progress through them. But hopefully you can follow the sequence. I will indicate if I'm going to a new slide.

 So while there are certainly limitations to automated tools and computer-based systems, computer-based systems can do an okay job of telling you if your site has obvious accessibility issues. There are certain patterns in things they can analyze on a webpage that are certainly going to cause an end-user issue. And automated tools can do an okay job of identifying those things for you. Beyond that it's always great to take some human testing and evaluation.

Okay next slide. Okay a few things about our philosophy. The way in which we have designed and built the wave accessibility tool. Primarily we focus on end-user accessibility. That is really what we want to focus on and emphasize, is ensuring that we are supporting good accessibility. To help support that one of our internal rules or guidelines that we have is that we should not indicate that something is an error unless it truly has a notable impact on end-users. We know there are some aspects of accessibility that we can probably identify in wave that have known or negligible end-user impact and so we don't focus on those things. We also want to ensure that we are not... I guess indicating to wave users that they should be addressing something that does not really matter. And many tools out there, evaluation tools take a pretty broad interpretation of accessibility or accessibility guidelines and standards and may be a fairly broad interpretation of what an accessibility error or issue might be. And that tends to cause people to address to make the errors go away within the tool without understanding why, why was this an error and what was the impact on the end-user. Sometimes that approach can cause people to fix things again, that have no impact on the end-user. So that is one of our things. If you ever see something in wave that is being flagged as an error that does not have end-user impact you let me know because we will fix it. We want to make sure that we are focusing on the things that are most important and those are going to be notable end-user accessibility issues.

Along those same lines we do not constrain our testing to the web content accessibility guidelines or [inaudible] any other really to find a standard. In other words, we test things and will indicate or flagged things in our evaluation that are not identified in the accessibility standards. But that we know have an end-user impact. An example of this, very basic example is small text. Very tiny text is something that is not [inaudible] a WCAG failure or Section 508 failure not something within the guidelines that addressed text but we know that has an impact on users it has a more significant impact on end-users with low vision so it is something that we do flag in wave. That we will at least indicate this is really small text. This is something you should probably be concerned with and may want to address. So that is an example of how we test things beyond WCAG. We do not test anything in WCAG, no automated tool can, no tool can tell you if you're site is accessible no tool can tell you if your site or page is compliant, they can only identify real obvious issues. But another thing that wave and accessibility tools can do is they can facilitate human evaluation. If that human evaluation is always necessary, if it's always required to ensure end-user accessibility then tools can help support that and that is really what we do with wave. We show errors for things that are obvious and then we help the end-user evaluate all of it least, maybe not all of the other stuff but many of the other aspects of accessibility that would be necessary for them to ensure that something is accessible or compliant. So what wave does is shows you the original webpage and then injects icons and indicators into the page to provide feedback about accessibility.

 Many or most accessibility tools out there will generate like a text type report. Saying you have this type of issue in your page, or you have this WCAG failure in line 27 in your code. And that can certainly be useful but our approach of facilitating the human evaluation, we feel that it works a little bit better if you are actually interacting and engaging with the page itself. It allows you to see the potential accessibility issues in the context of the page itself. As opposed to being entirely isolated in the separate text type report.

So that is the idea of wave. We just reveal the underlying accessibility problem and features and things that we think you should look at and determine for yourself as a human whether it may impact accessibility.

With that it is important to understand that web accessibility is by its nature very much a technical thing. Wave does require at least, I don't know if require is the right word, but it's usually best utilized if you do have a basic understanding of web accessibility. But we have also built wave to teach you along the way. It helps inform you about accessibility, it helps to help you learn why a particular thing is being identified in the page. We help you understand why this thing is being identified, what the impact is on the end-user, what you need to do about it and how you address the potential issue. So even without any background in accessibility are hope is that you can analyze the page in wave and learn a little bit more about accessibility along the way.

Okay, next slide. So a little bit about how wave works. It is, the approach, the way in which wave conducts its evaluation has changed a lot over the years. I like to say that it's kind of magic. I think so. The way in which we currently perform our evaluation has changed in just the last year or two. And it has become in some ways more simple and in other ways much more advanced.

 So the user goes to the wave webpage. They submit a webpage address. When they do that it's going to load kind of interface and components in the evaluation engine into the web browser. It's a fairly complex web application. Most of the evaluation used to occur on our server. They would perform all of the evaluation logic and generate this big, the original page with the icons and indicators built in and then it would send all this back to the end-user. The approach now is that as soon as you type in the webpage address the server gets to the page and sends it to the end-user into this web application. And that is where the evaluation occurs. It's actually within the web browser itself. The web application will render the webpage and perform the evaluation directly within your browser. And we have found that that provides a little better indication of end-user accessibility which is the evaluation is happening directly within your web browser as opposed to on our server in the browser that we have defined. And so that seems to work a little bit better. It also seems to be a little bit faster. It decreases the server load and processing power and requirements on our and because we have passed on most of the work to your computer.

With that said it's really quite quick in the way that it does the evaluation. As soon as that evaluation is concluded we show you that original webpage and then we inject into that page the icons and descriptions that give you feedback about accessibility and then the interface is structured in a way that supports you going through and performing human or manual evaluation.

Okay moving on to the next slide. As I mentioned wave shows you the original page and puts icons and indicators into the page to give you feedback about accessibility. So this is a screenshot from the web aim site. It shows the web aim logo. And adjacent to the logo there are two icons that wave has injected there is an H2 icon. The icon indicates that this element is engaged to a second level heading. Also adjacent to the image is an alt icon. And this one has a little mouse finger cursor that indicates that this is a linked image that has alternative text. So it is a green icon and we will talk about the colors but that indicates there's probably something here that supports or facilitates accessibility. And wave also presents the alternative text for that image. So this takes something that otherwise was invisible to a sighted user, the fact that not only is this an image, but that this image is within a second level heading and that this image has alternative text and this is what the alternative text is and it allows you to see that visually within the page.

So again it is taking the underlying structure and semantics and accessibility and is bringing it to the forefront in a more visual presentation so you can now see well is a second level heading appropriate for this image. Is this alternative text equivalent to the image itself. Is it appropriate alternative text. It allows you to do that in a very visual and hopefully easy to use way. We often get the question about accessibility especially for screen reader users of wave. Because this is a very visual presentation with the icons and indicators the question that accessibility. Spent a lot of time and a lot of work to ensure its highly accessible.

 With that said we know there are some complexities. It's a fairly complex interface in what we present but we do add alternative text to the icons. We built in keyboard accessibility and things like that into the interface itself. If anyone is a screen reader user and can give us feedback on how we can make it better we'd love to hear that but we do get reports from screen reader users that utilize wave and find it to be accessible. With one big caveat there. Wave does not fix the accessibility of your page. So if there are accessibility issues present in the page that you are evaluating those accessibility issues will still be present. We cannot magically make those go away. Hopefully wave has identified those accessibility issues and made them apparent to the user. For instance, an image that is missing alternative text and wave would display an icon and that would be accessible to the user, but the image itself would still be inaccessible to a screen reader user. In some ways that is really helpful. And feedback we have received from screen reader users is that it allows him to perform evaluation and identify issues that otherwise they wouldn't. Because sometimes it's hard for screen reader user to identify that something is accessible because it is inaccessible. They may not even know that they are missing something. And if wave identifies that to know of that accessibility issue when otherwise they may not be able to identify the issue well.

So this is the way that wave works. It will display these icons and this wave generated text. The green background color for text indicates that this text is wave generated. It's something that wave has pulled from the backend, the code of your page and is presenting it visually so you can see it. If you see trapezoid -shaped icons, it's kind of a box but it is more narrow at the top that the bottom, it indicates that that particular icon is related to images which is another graphic queue or indicator that this particular type of icon is related to an image within the webpage.

Okay, so a little bit more about the icons that may be presented within wave. Red icons indicate accessibility errors. Again, if you see red there almost certainly is an accessibility issue. We really tried to ensure that that is the case. Almost all red icons would also indicate a compliance failure, so something you would need to address in order to become compliant. Now very often people ask about our usage of color. We don't rely on color alone is the only way of indicating errors and other types of icons, so you can always, based on the shape of the icon the presentation of the icon itself or by clicking on an icon or interacting with the interface itself even if you could not perceive those colors there are still ways to identify the particular categories of icons, again, and accessibility feature that we built into wave. Yellow icons indicate alerts. So alerts are things that you should probably look at.

We have identified it or flagged it because they may cause accessibility or usability issues but we can't necessarily be sure of that. They very likely could be, but we want you as a human to look at it. So if you see red, you know that is an issue but yellow is something that as a human you need to go and evaluate on your own. Again, we identify that is something you need to look at and determine for yourself but is it an issue or if it is an issue what is the impact of that particular issue on the end-user.

Green icons indicate accessibility features. Those are probably good. Not always. You still as a human evaluator must determine if they are implemented appropriately. Typically with accessibility features we also reveal additional information to help you determine whether it has been implemented correctly. An example is alternative text for an image. Not only do we show the icon that indicates that there is alternative text but we also show the alternative text itself so you can determine whether it is equivalent to that particular image. Most other tools are simply going to say hey, there's alternative text yes you are good to go. Yay. Wave says yea, you are probably good, here something that's probably been implemented for accessibility but here is some additional stuff you can use on your own to determine whether it has actually been implement it correctly or not.

The category of blue icons indicates structural and semantic elements. So, things like headings, lists, tables all fit into this category of blue icons. And they can be really helpful in determining just again the structured semantics of the page to make sure that accessibility has been implemented.

There are purple icons, and purple icons are HTML 5 or aria attributes or elements. So this is something relatively new to wave that we identify HTML 5 structural elements, at least the ones that would have an impact on accessibility. Things like net of, main content, the main element header, food or, those cannot be navigated by screen reader so we draw attention to those tools, and aria, there are several different types of aria icons like HTML 5 structural elements can facilitate navigation. These are things that are buried in the code of your page. We provide visual indication so you can evaluate them.

In the final category is a single contrast icon. It is a red icon that indicates that there is a way Level to high failure contrast. We have isolated the contrast issues from the others. Mostly for usability. Partially because in many sites there are so many of these that actually viewing them in isolation from everything else tends to be a little bit more easy.

 You don't have to rely on this tiny icon itself to figure out what it says you use wave you become more and more familiar with what it means but you can always click on a particular icon to learn more about it. It will show you a nice tooltip and give your brief expedition as to what the icon means and there's additional documentation in the interface I will show you that in just a minute. You want to point out I think I've said this in a few different ways but just because you don't see a red error icon it does not mean your page is accessible or compliant in any way. It just means that wave, even as a stupid automated tool and they are all stupid if you think about it, it can only do so much, wave has not detected something that it knows can cause an accessibility issue. Additional evaluation will be necessary to determine true accessibility.

Okay next slide. Just a brief introduction to the interface itself, then I'm going to let you play with wave for a few minutes then we will come back and wrap up. There are three primary views within wave. That is what we call them is views. Different ways of viewing the accessibility information. The default view is a styles view. That means all the styles for the page have been applied. All the CSS is present within the page. That is the default presentation. It allows you to view your page up as it would generally appear within the browser with our stuff injected with Intuit. There is a no styles view all it does is turn off the page styling in CSS that has been applied. It also linear rises at the page, things like tables, the structure of the table is removed so you see the underlying reading and navigation order. That is a great tool for accessibility that allows you to ensure that the order is logical and intuitive. That is the order in which a screen reader will read through content in a page. It's the order in which a keyboard user will navigate through the page. So selecting those styles allows you to ensure that that order is logical and intuitive. Generally that it follows the visual presentation order.

Another thing that most styles does is it simplifies the wave presentation. Because we inject icons and text into the original page sometimes that has a tendency to clutter the page a little bit. It can sometimes even break layout and can appear little bit weird if the pages designed in such a rigid way that by us injecting our icon it may tend to break things. Most of the evaluation that I do I do in the no styles view just because it cleans things up and makes them a lot easier. Another advantage of the no styles view is occasionally wave will identify an issue where it will inject an icon into an element that does not appear visually within the page. So wave may indicate that there is an accessibility error but you may not see a red icon within the page. Usually it means that the error icon is within some element that has been hidden with CSS. By selecting those styles and disabling that CSS and styles in the page you can see the underlying content and the wave icon will then be visible within the page and you can actually view it, see it in the context of where it is. Devoid of all the extra styles. So 90% of the evaluation that I do, the time I spend in wave usually have the styles view enabled.

And the final one is contrast. That will show you only the contrast issues. Wave does do what we might call smart contrast analysis. Many tools out there that test contrast, potential contrast issues will evaluate all foreground and background colors for every combination. Things that may be present in the page. And they may alert you that this foreground and background color do not make the WCAG AA requirements, but sometimes they do that if there is not text rendered in those particular colors. That may cause you to think there is a WCAG color or contrast issue when one is not present at all. What wave does is actually looks for text. It ensures that it is flagging a contrast issue that there is actually text on the page rendered in that foreground and background color. It is it is thus an actual end-user issue and compliance failure. So we try to build and it turns out to be pretty complex to do that type of analysis if you consider CSS inheritance and nested order and things like that but we've done all the work for you so you don't have to worry about it.

There is a wave sidebar it appears on the left-hand side of the screen. There are four tabs or kind of panels within the sidebar. You can activate those by clicking the tabs or navigating with the keyboard on the tabs on the left-hand side. There is a summary that will show you an overview of the wave results. How many errors, alerts, features, how many things are there in each of those categories that I talked about. There is a details panel. The details panel will allow you to see all the wave icons that are present visually in the page grouped by type or category. So you can see all the errors together and all the types of errors. All of the alerts and individual categories for those. You can turn on or off individual categories or subcategories of particular things.

So let's see if you wanted to turn off all the alternative text issues you can click a checkbox and they will immediately disappear dynamically from the page itself. So it just allows you to clean up and filter things down to what it is that you actually want to focus on. There's also a built-in filter option that allows you to filter down to WCAG AA, 2.0, AA or Section 508. So it just turns off particular types of icons that do not map to those particular guidelines.

 We do not draw too much attention to this. Primarily because we would not want someone to say oh, well I'm only interested in WCAG level A, and ignore other errors or issues that we know have an impact on the end-user. There is that functionality built in. There is the documentation panel. That will provide details on every particular icon. It will give you details as to what that particular icon means, why it matters, what is the impact on the end-user. We only want you to know, we don't want you to fix issues blindly. We want to know why you are fixing them, what the impact is on a particular user. We tell you how to fix it. We defined the algorithm, hopefully in English. There's a lot of complexity too much of the logic that wave is evaluating and we tell you what is it in your page that caused this particular icon to appear. And then we also list any standards or guidelines WCAG or section 8 theories guidelines that are relevant to that particular guideline.

 Then the final panel in the sidebar is the outline panel. It shows you the outline heading structure of the document so you can see the document structure the order and the levels. So there's a first level heading, second-level heading that will also indicate potential heading structure issues such as a heading level that may be skipped. Let's say you jump from a second level heading to a fourth level heading. We have an alert icon that indicates that so you can determine whether there's potential end-user impact because of that.

 We also have a code panel. At the very bottom of the page there is a little button or knob kind of thing that you can click on for code that will open up at the bottom that will show you the underlying code of the page. This is the rendered code in the browser that doesn't always map original to the HTML [inaudible] it shows you the icons relevant to the code. You can actually see the icons of the context of the HTML of your particular page. And there is an attraction between the code panel and the page within the visual page and the sidebar. You can click on any particular icon, so it's, every icon really appears three times, it is appearing in the original page. It will appear in the context of the code and the code panel and the sidebar. If you click on any of those icons the other two presentations will adjust to highlight or focus or scroll into view that particular icon. So if I find to say a form right in the page if I click on the code panel click the icon in the page and show you the issue within the code. And you can look at the code and say why is this form error here. Is there no label? Is there a mismatch between form and ID, [inaudible] don't worry about it but for more technical users this provides a great way to actually get into the code of the page and analyze it.

Okay so let's go ahead and take maybe five minutes or so. I want you to just go out and play with wave for a few minutes, run a page and we will see how this works whenever but he hits the server at the same time. It's not going to work well for me to walk you through this activity because of the way the shared browsing works but just go out to wave.web aim.org, type in your website address or a website that you are very familiar with. And perform the evaluation. If you have any questions please come back and chat and I will do my best to answer them. Let's take maybe five minutes or so and let you explore wave and if there are any questions again please jump in at any time.

 Okay. I will give you another minute or so. If you want to keep playing with that we will maybe just address some of the comments. There was a comment that it was not jumping if you click on an icon it was not jumping to that location in the code with the zoom text running. That is an interesting issue. I don't know if that is a bug. It seems to be something maybe with zoom text. But I have made a note of that and we can look into it. Joshua noted that it is not seeing your website front page as publicly available. If you shoot me an email that is something we can look at. We are aware of there are a couple of little bugs or issues I guess with wave with some pages, one deals with encryption if you have SSL HT TPS page, some pages that use newer SSL technologies are not currently compatible, so that is something that should be fixed shortly something that with very few pages there may be pages that have scripting or something else in them that may be blocking wave so Joshua if you maybe go to web aim, or actually there is a contact us, or option there in wave, send us an email and I'd be happy to look at that particular instance and see if we can figure out what is going on. You've got my email, perfect I'd love to look into it.

  Any other questions anybody has about wave and how they are using it? Okay, Andrew had the comment that he's testing with Firefox and and BDA, but he could not get to I think what he is saying by clicking on a particular icon it did not directly jump into that in the page. That's correct. That's the anticipated behavior you know, activating or clicking on the icon doesn't actually jump you to that. It really just highlights and visually within the page. You would then need to go in and read to it or navigate to it. We had a lot of debate about this and in testing we just found that by automatically jumping the user into the page that they entirely lost the context of being in the sidebar or the code or wherever they were at, and just found it best to more do the visual highlight and the user can still navigate to that. And we tested both approaches, the current approach and the other one just found that jumping them out of the context, that the sidebar tended to be more confusing to users. But I'd be happy to maybe look at that more, or if you feel that would actually be more beneficial we could review that.

Okay let's go ahead and I've got just a few final things. Okay, with a screen reader how would I know where on the page the issue is? There is the icon within the page so you can go ahead and read through the page and it will be identified when you encounter that within the page. So it is kind of, again there is a dilemma by having those isolated in not being able to link directly to them. There is an issue if you do link then you are kind of jumping all over and it can be difficult. Anyway, it's an interesting question I'm glad that you brought that up.

 Okay, a few final things on wave. As has kind of been hinted to we do have a chrome extension. This is an extension that you can install directly into the chrome browser. And it functions almost exactly the same as the wave website evaluation tool. The difference is that the evaluation is conducted on the page directly within your web browser.

So this allows really any webpage that you can open within Firefox I'm sorry not within Firefox, within chrome browser to be evaluated, so if you have an Internet page password-protected page, something local on your computer if you can open it and look in the chrome browser you can simply activate the button within the interface and it will evaluate that page directly within your browser. So that it does evaluate the current dumb state, essentially the living version of the webpage within your web browser after the CSS has been applied after the scripting has been applied even if you have a very dynamic page you can manipulate it into that page that so you can open a dialogue window a particular tab within the dialogue or maybe there's dynamic content being loaded into the page you can get the page to the particular state in which you want to evaluate the accessibility, click or tab two and hit enter on the wave button to trigger the evaluation on the current state.

So this is really the best evaluation or representation of end-user accessibility because you are an end-user. You are evaluating the page directly within your browser in the state in which it has been built. So the chrome extension is highly advised if you are doing a lot of evaluation and it's also faster, it's very secure. There is no data being transmitted to our server, it's done entirely on your system.

 So, Norm asked the question do you still have a Firefox extension. No we don't. We don't have a Firefox extension now. But we are working on it. We actually have a working alpha version of a new Firefox extension. We used to have a Firefox toolbar. For various reasons I won't go into a lot of detail but the Firefox platform no longer supported the functionality of our toolbar and did not support the functionality that we needed to do the cool stuff that we were doing with wave with the sidebar and code panel in this interaction. It simply did not support it and we were not interested in addressing the bug to lattice to build the functionality needed. So we did have to pull the plug on the Firefox extension but we are working on a new version now to help support the things necessary and we hope to have that soon. Do not ask when but soon. There was another question that said we got different results from the chrome extension and the online version. Are there different versions.

 If you did get discrepancies or different numbers types of errors and things like that between the two versions it usually means one of two things. It may be that you're serving slightly different information to our server with the online version as opposed to your browser with the chrome extension. So that may be the case. Maybe if there is dynamically generated ads within the page you might get different ads each time the page is loaded. There might be browser specific content. Okay, your server might say oh, if is the chrome Firefox browser were going to send this content if not we are going to send this. That may be one explanation. The second explanation might be that within the chrome extension after the page is fully loaded and all scripting has been applied to that within the online version there are some limitations in full analysis of scripted content. So that would be the other explanation.

 Then there is another question. We are encountering pages with thousands of our ENA features can we separate those. You can you can go to the page the REA five category there's a checkbox for that and you can check those off and make them invisible in the page. There isn't a way to do that directly when you process the page but once it is loaded you can turn off that particular category.

 Okay, so chrome extension. That is really cool, what I use most of the time for various reasons. It's just a little bit more, slightly more comprehensive test of the page. And much faster. Oh, so the clarification, can we separate REF from HTML 5, yes kind of. Not directly into those categories, but you can go into the subcategory so you can turn off individual HTML 5 icons or individual HTML icons we do have a catch almost aria fits into one category so if you want to turn that off you could go into the subcategory and uncheck the checkbox to turn those off.

 Andrew's comment that it keeps threatening to write an article with the title something like if a little aria is good, when is more aria too much. Absolutely it drives me mad too. Actually have an article that I wrote several years ago that is entirely relevant today that is entitled aria gone wild and it's very much the case. That's why we have to put a lot of effort into the aria evaluation within wave is to help draw attention to that and we have a whole bunch more that we are wanting to do especially with HTML 5 and aria to help address this abuse and overuse and misuse within aria. There's a lot of logic we are going to build into wave to help people do that type of evaluation.

Okay there is one other type of wave version that is available, that is the wave API. API is an application programming interface. While the real power of wave is in evaluating a single page at a time, really getting super deep into the details of the accessibility of the page and having the interface present that accessibility information to facilitate human evaluation, we know that some people really just like the wave evaluation logic. The things that we identify with wave. That they would want to evaluate many pages using that as opposed to one page at a time. For that reason, we do provide this API. With the API the way it works is you send the API a URL, it returns back to structure data about the accessibility of the page.

 Essentially for every icon that you see within wave it will give you data about that particular thing. So, you could for instance run the API I and process all of the pages on your site and find a home they linked images with alternative text are present. How many unlabeled form controls there are. How many pages are missing document language. That type of thing. Now it is in API. Would you send a URL we give you data what you do with the data is very good, you need to build something around the API to be able to collect that information to put it into a spreadsheet or report or database or provide some visual presentation of the accessibility issues on those pages or sites. So it is the brains of wave. It is the wave engine that we allow you to have access to. So the idea is you can evaluate a lot of pages very quickly. One university system is utilizing the API and analyzing over 100,000 pages every couple weeks and providing reports. In comparison and tracking progress over time, things like that.

 Andrew asked the question how does API deal with dynamic pages? It can perform the evaluation after scripting has been applied but it's really capturing the default state of that page. With that said, we have had people that use the API with other tools that can manipulate the site content or functionality, things like selenium which can actually trigger interactions with the page and capture that state and evaluate it with the API. It does not do it on its own but you can build tools around the API to do that.

We have two versions of the API. We have a hosted version that starts at 2 1/2 cents per page. So if you don't want to deal with installing things and all of that you can use our online API, it is a subscription type thing. You give us 10 bucks and go evaluate hundreds of pages if you want to, something like that. Then we do have a standalone API where you download and install it onto your own Web server and perform the evaluation that way. Now we have been licensing the standalone API sometime in the very near future I am hoping like next week if we work out a few bugs we are going to be offering a new version of the standalone API for free. For most users. As long as you are not reselling the results and things like that if you wanted to test it for your own site we are going to be offering this for free. So we are really excited about this as a way to help support accessibility for large-scale type applications and sites.

So you can read more about that at wave.webaim.org/API.

So just a few notes on the future of wave, mentioned the new Firefox extension on API will be released for free in the very near future. The idea everything the standalone API is that people can then build tools that can be provided freely and open source around the API. Things like spidering the website to collect all the URLs for evaluation, reporting engines and analysis and reports for the sites tracking changes over time that type of thing. People have Artie built some of these and our hope is that people will build other tools that anyone can use that utilize this API and a whole lot more. We are always trying to think of ways and we are working on it continually and would love to have your feedback and recommendations.

With that I will say thank you. Maybe we will take another minute or two of your time if you'd like and if there are any questions I will go ahead and address them now. And I do have to note that I'm sorry I cannot hear Norm or anybody else. I cannot hear the audio so you have to post it in chat and with that I'm just going to say thanks Norman thanks for the invitation to present at and love to see you next week we will dive in and do more evaluation in the webinar next week.

 I want to thank our captionist, Mary. See you all next week.