Transcript
Peter Berg
Welcome everyone to the March session of the ADA audio conference series, here in Chicago, we are looking at a balmy 50 degrees or so. I hope wherever you are, you are enjoying some bright weather and the wind is at your back. The ADA audio conference is a program of the ADA National Network, ADA National Network is funded by the U.S. Department of Health and Human Services administration on community living National Institute on Disability independent living and rehabilitation research. You can locate the regional ADA center that serves your state by visiting ADA P.A..org. The ADA centers provide guidance and training on the Americans with Disabilities Act. As Natalie mentioned, for those of you on the telephone, when we get to the portion of the session today when there will be questions, we will bring Natalie back to give those instructions again. Those of you participating through the webinar platform as you heard earlier, you can submit your questions in the chat area throughout the session, so hold on to your questions, get those questions in early.
We are pleased to have with us Jared Smith, associate director with WebAIM, talking about a very important topic, very hot topic as it goes, and the application of the Americans with Disabilities Act to websites used by state, local governments and places of public accommodation and businesses for profit nonprofit and what it means to have accessible websites accessible technology. We are pleased at this point, I'm pleased to introduce our speaker, Jared, and welcome, and I would like to turn the session over to you at this time.
Jared Smith
Okay, thank you, Peter for the introduction. I appreciate the opportunity to be here, and to talk about the ADA and websites. I'm Jared Smith from WebAIM, WebAIM stand for web accessibility in mind, we are a nonprofit web accessibility consultancy based at the center for persons with disabilities at Utah state university, we do web accessibility, that is what we are passionate about, we help to educate and empower organizations to build and maintain their own accessibility over time. I'd invite you to check out our website, there is a wealth of resources, research, we have a on-line community around the topic of web accessibility. Today, I'm going to talk about the ADA and websites and what is required with those. I'm going to build into this a little bit, I think probably for this audience, as I go to the next slide, number 9, I probably don't need to say too much about those with disabilities. We know about 20 percent of the population has a disability, over a billion people on this planet. As we analyze the types of disabilities that are reported, and most of this comes from census data, we know that about 8 and a half percent of the population has a disability that can impact computer use. This is a very minimal number, it does not include those with cognitive or learning disabilities which arguably is larger than eight and a half percent all by itself. It doesn't include those with colorblindness, which would be around 3 and a half to 4 percent of the population. And a few others.
We can look at that 8 and a half percent and consider for ourselves what that might mean for us, what the impact is, whether that's a big number, whether it's a small number, it's hard to say. The biggest thing that I want to stress is that we are talking about people. Regardless of numbers, regardless of technical requirements, regardless of what the law says, it's most important to consider that we are talking about people, and people that can be significantly impacted for good or for bad based on your decisions when it comes to web accessibility. For many with disabilities, the web is a primary mechanism for them to engage in commerce, in education, in banking and all of these other things that we enjoy and maybe take a little bit for granted on-line, the web is really just a god send and such a amazing resource for people with disabilities to independently engage using their own technologies, taking the time that they need in the way that they need and entirely on-line, so long as what is provided to them is built with accessibility in mind.
One interesting way to think about this 8 and a half percent, isn't just that we can extend our reach to this population by implementing accessibility, but that we can really maybe see it as a market opportunity, and maybe it's a ethical opportunity to really have a notable impact on their lives. The next slide, there is a photo here of the iPhone. When the iPhone was first released, it had very good accessibility built into it, very accessible to many users with disabilities, including users that were blind. It wasn't perfect and still isn't perfect. But it is very accessible. If you are blind and you wanted a cool phone, where you go into purchase a iPhone or a phone that was inaccessible to you because you hadn't been, it hadn't been designed with accessibility in mind and of course you are going to purchase a iPhone. We saw in a short period of time a significant shift in the disability community to iPhones. Then iPhones and iPads and then iPhones and iPads and Mac Book Pros and Android and others have come along and now support good accessibility but Apple was there first and surveys that we have conducted at WebAIM on users with disabilities show that adoption of IOS up a he will devices is significantly higher -- apple devices is significantly higher among the disability community than other populations, enough so that it's safe to say that users with disabilities represent a part of Apple's market share. Maybe Apple was seeing dollar signs in their decision to implement accessibility into these devices but the reality is that it's had a notable impact. I've heard from blind friends and colleagues that said the iPhone is the most significant impactful thing that has improved their lives ever, period. That is pretty amazing, I think. I love my iPhone, but I don't think that it has been that impactful on my life, and I think that is an interesting way to view accessibility, is not just extending your reach, but people with disabilities can come to you to get services, information, resources, products that you provide. My focus will be on individuals with disabilities.
But as I go to slide 11, there are additional benefits to implementing accessibility, as we consider making websites that are more compatible with the assistive technologies that people with disabilities might use, and you are making it more compatible with machines and Google is a big machine and we see a lot of additional benefits to search engine rankings by implementing good machine compatible accessibility. You might consider for a moment this next question, and I use that term assistive technology, and that is some sort of technology that due to a physical issue or limitation, if you didn't have that technology, you would have difficulty functioning the way that you do every day. It's interesting that assistive technology is actually quite common. I suspect that there are many of you that may be really do use traditional assistive technology, that probably very many of you that wear glasses or contact lenses, and those of you that wear glasses or contacts, I suspect that maybe most of you would have difficulty functioning the way that you do every day if you didn't have that assistive technology, as glasses or contacts. Is this an assistive technology? Or maybe another way to ask the question is do you have a disability? If it sounds like you couldn't function the way that you normally would without that assistive technology, then maybe you do. But most people that wear glasses or contacts don't consider themselves to have a disability, and that is primarily because their environment works with that assistive technology. Imagine if you encountered a website that didn't work with glasses or contacts, suddenly that would make that disability and really something that maybe you haven't considered a disability would suddenly make that very relevant. The there was no disability until the barrier was introduced, the incompatibility was introduced to that assistive technology. In some ways that site disabled view, in a way that there would have been no barrier otherwise. It's a interesting way to think about accessibility, is compatibility with these technologies. There is much more to accessibility than making things work with technology. We want it to work for everyone, and there are many additional benefits to accessibility beyond assistive technology, and even beyond those with disabilities, but that will be our primary focus.
As we think about accessibility, I think it's helpful to consider accessibility as being a continuum. Something that we can continually improve upon, that we can be better at, because we are talking about the human experience, which is humans are so dynamic, it's hard to define accessibility as this like an on/off state, right? Like suddenly we hit a threshold and ta-da, now we are accessible. That is not really how it works, because of that really dynamic human nature of accessibility and of disability. It's useful to view accessibility as a continuum, something we can always improve upon. I was just 15, 20 minutes ago making improvements to accessibility on the WebAIM.org site. This is a site that has been significantly designed and built for accessibility, and we have strived hard to make sure that it works well. But there were a few things that I noticed I wanted to refine and improve, to increase where we are at to move along that continuum just a little bit more.
It is helpful to have measures along the continuum of accessibility. Slide 14, we have brief overview of the Web Content Accessibility Guidelines, WCAG, or I may say wick-ag, I'm refusing to the web content accessibility guidelines. These are international set of guidelines defined by the Worldwide Web Consortium, the W3C, which is the standards body for the web. They define html and CSS and these other technology standards that we use to build the web. They have a set of accessibility guidelines. These guidelines are designed to be very principles based, the four foundational principles of these guidelines are perceivable, operable, understandable and robust, or POUR principles. These are nice principles to think about, when we consider accessibility generally, we want things to work for users. We want them, our content to be perceivable, to get it to their senses in a way they can start to do something meaningful with it. Once the user can perceive content, they want to be able to operate and navigate within that. It needs to be understandable and make sense to them. It needs to be robust, needs to actually work with the technologies and assistive technologies that they are using.
Those principles form the foundation of these guidelines. Below those principles we have what are called guidelines, they are very high level statements, about accessibility. Things like provide alternative text for nontext elements, make keyboard accessible, don't cause seizures, very high level principle. Then below those are success criteria, that is where the rubber meets the road. That is where we measure conformance or compliance with the guidelines themselves. Every success criterion is assigned a level, A, AA or AAA. The A criteria those are foundational aspects of disability. If you don't meet the single A things in WCAG you are going to almost certainly introduce significant barriers to users with disabilities. Some may not be able to access your content at all. The AA success criteria those are, add and extend the single A things, double A would be things if you didn't implement those, that users may have more difficulty or frustration or take more time accessing your content. Then AAA, those are more enhancements to accessibility, that may provide some benefit for some users with disabilities but generally are more difficult or burdensome to implement and it may not even be relevant for all websites or web content.
The way the structure works is, say if your goal was to be WCAG 2AA complaint, that means you would also need to meet the single A requirement. To be AAA you would need to meet all the A, AA and AAA success criteria. AAA isn't a goal, shouldn't be a goal or objective for most sites. But there are a lot of good things in there that you can reference to enhance accessibility.
That is a overall view of the structure of these guidelines. The first version of the Web Content Accessibility Guidelines was finalized in 1999. This is not new. We have had guidelines for a long time. They were updated in 2008 to version 2.0, and then June of last year, that version was updated to version 2.1. With 2.1, what happened is new success criteria were added. 2.1not change anything in 2.0 itself, it just adds new success criteria, primarily in the area of mobile accessibility, mobile web content and mobile applications, because in 2008 this was really just kind of new. The W3C is currently working on updates to these. With a anticipation that we will see more frequent updates to these guidelines in the future.
These are just great resources, these guidelines. They are not perfect. They don't cover every aspect of accessibility. But they are good guidelines. They are good measurement for accessibility, and certainly what we would recommend as being a primary reference when it comes to accessibility. Moving to slide 15, we have a checklist on the WebAIM site. Because the guidelines are very principles-based and they kind of use this confusing and ethereal technology agnostic language, it can sometimes be rather difficult to understand. We have created a checklist on the WebAIM site that boils down that weird fuzzy technical language academic language, and makes it much more approachable. This can be a useful resource and it's available at WebAIM.org. It's six or seven pages, covers all of the aspects of these guidelines in language that's more accessible, more usable and understandable to hopefully, to most everyone.
Next slide, it is important to consider, however, that your site can be compliant yet still be inaccessible. If we view accessibility as a continuum, these compliance with the guidelines means that you met one particular threshold or measure along that continuum. That means that there will always be users with disabilities that may still find your content difficult or inaccessible. We need to think about users beyond just compliance.
To take this a step further, on the next slide, your site can be technically accessible yet functionally inaccessible. That means that you can implement the technical aspects of accessibility, yet still have a experience that functionally is not friendly to people with disabilities. The example I like to use of this is if you consider someone that may have difficulty using a mouse or a touch pad or touch screen, very often somebody with a motor disability, may interact with a Web Page using the keyboard. You can hit the tab key on your keyboard to navigate through interactive elements. Think for a moment about your website, or maybe a site that you are very familiar with, how many times would you need to hit the tab key on your keyboard from the very beginning of that page to the main content area, maybe you have to navigate through the logo or site name, maybe a search field, maybe navigation has drop down or file menus, maybe a sidebar, breadcrumbs, other types of things before you get to the main content area. It may be that you hit the tab key a few tiles, it might be a lot -- a few times, it might be a lot, it might be a whole lot, we have seen as many as 600 navigation items on a Web Page that have to be navigated through before you can get to the main content, and on every single page of that website. That is actually technically accessible. It is even compliant with the guidelines. The guidelines say the website needs to be keyboard accessible and it is, but is that functionally accessible and consider somebody that has significant motor disabilities, former colleague of ours used a stick in his mouth to interact with the keyboard, imagine with a stick in your mouth having to hit that tab key 600 times. Technically accessible, yes, compliant, yes. Functionally, accessible, probably not. Users aren't a going to engage in that. We want to use the guidelines as guidelines. We want to favor accessibility over compliance.
We want the guidelines to guide, to help inform a good end user experience with the understanding that the guidelines do not ensure accessibility.
We want to focus on the user primarily. Slide 19, we are going to get into the legal aspects a little more. I want to start with Section 508, this is something that is very often referred to in accessibility and compliance. Section 508 is part of the Rehabilitation Act, it applies to federal government. That is the scope of Section 508, applies to development and building, purchasing electronic and information technology within the federal government. On the scope of the law, Section 508 is federal government, it defines technical standards that often have a much broader scope, because the federal government is big. As an example a federal agency may provide federal funding and may require compliance with the Section 508 guidelines, as a requirement of receiving those federal funds. That wouldn't mean that Section 508 the law directly applies to those recipients of the funding but the technical requirements in Section 508 do, because the federal agency has dictated that, because the law does apply to them. Many states have adopted Section 508 guidelines as state law, sometimes with modifications. A lot of states also include these standards with various levels of scoping. Sometimes only the state agencies, sometimes the state agencies and say public education institutions, to some extent broader than that. Section 508 was updated January of last year to incorporate the Web Content Accessibility Guidelines 2.0 level A and level AA. Those guidelines are now the technical requirements for Section 508 for web content. That is another motivation for looking at those guidelines. Of note is this is version 2.0, not version 2.1. We don't anticipate an update to Section 508 to WCAG 2.1, in the near future. It took us about twelve years to update it to WCAG 2.0, and we are glad that that finally occurred last year. But for now it is 2.0A and AA success criteria. Another term I want to cover and that is VPAT, Voluntary Product Accessibility Template. This is a standardized template defined by industry to allow a standardized mechanism for documenting compliance with Section 508. So a lot of say corporations want to do business with the federal government, this provided them one standardized template whereby they could document how they meet or don't meet the requirements of Section 508. We are however seeing the VPAT in a lot of other areas. States, state education institutions, even some other businesses are now starting to ask for or require a VPAT as part of the procurement process. So it's a mechanism where you could have a vendor define the document, their compliance with technical requirements with Section 508 which is now WCAG 2.0A and AA. It is important to be familiar with that term, if you are either, maybe selling or providing products and may be asked for a VPAT, if you are in a position to procure products that can be a way for you to get documentation about compliance, with the understanding that trust verify when it comes to this documentation.
Moving to slide 20, now we are going to get into the Americans with Disabilities Act. The ADA predates the web, the word web, the word Internet does not appear anywhere within the Americans with Disabilities Act. That's just one of the most important things, we will talk about how does this or does this at all apply to the web, within the ADA itself, there is no direct mention of the web or Internet. There are three primary areas or titles of the ADA, title I is employment, this is really important that we don't overlook employment. Often entities as they consider web accessibility may start with their public pages, home pages, and most visited public pages, things like that. Maybe for education they start with student resources, and those are all important. Those are going to have a big impact on users but don't overlook employment. As an example, if you were to develop a disability and statistically most of us will in our lifetime, and you couldn't do your job because of the inaccessibility of systems that you are required to use, does that sound like discrimination? I'm not a lawyer, but it does to me. And the ADA clearly covers that employment. Don't overlook those internal systems, HR systems, intranets, employee applications, things like that. Title II is state and local governments. I include public education entities, clearly covered by the ADA. Title III is places, well, it's public and commercial facilities, the term often used is places of public accommodation. This has been a primary question for some time. Is the web a place of public accommodation? In other words, can a inaccessible website be considered discriminatory under the Americans with Disabilities Act? The answer, most of the time, to that question, has been yes. The web is covered by the ADA, the Department of Justice, the enforcement entity for the ADA has clarified that yes, they believe that the web is covered by the ADA, that it can be considered discriminatory, but what they have not yet done is defined any technical standard as to what that means. So, in short, to answer the question of what is required under the ADA, the title of this webinar, it's to not discriminate based on disabilities. That is what the ADA talks about. It talks about civil rights for people with disabilities, and discrimination. But it does not yet define technical standards.
Slide 22, this clarifies that, we don't have those technical standards yet for web content. We do have those for other aspects of the ADA. For instance, wheelchair ramp, there are technical requirements that the ramp can only be so steep. That is easy to measure. We have those technical standards, for how wide the door needs to be, the height of drinking fountains, we don't have any of that guidance when it comes to web or digital content. I sometimes equate this to being pulled over and given a speeding ticket on a street that has no speed limit signs. That is kind of the situation that we are in, that you could get pulled over and, what did I do wrong? You were going too fast. What is too fast? It can really be whatever that officer determines it to be. Because we don't have the mileposts, we don't have the speed limit signs for web accessibility. Now, with that said, we do kind of have some defacto standards. The lawsuits that we have seen, complaints to the Department of Justice, to the office of civil rights, within the Department of Education, Department of Justice settlements, have all generally required WCAG 2.0A and AA as the technical standards that measure of discrimination.
That is where it's at, again, are those guidelines, but this has not yet been defined. There was a process that was under way to define these technical standards within the ADA, that process has been halted by the current administration. We don't anticipate that there will be progress in at least the near future in updating these technical standards. This puts us in a nebulous position, where there are a lot of lawsuits, many lawsuits, the number of lawsuits last year, more than doubled the number of lawsuits in 2017. We are seeing significant increase in legal action, some of that I think may be driven by the fact that we are not seeing technical updates, and that the process is within the office of civil rights for people with disabilities to maybe get action or reprieve, they feel they have been discriminated against, where some of that has been pulled back or halted, they are lawyering up. They feel that that is a mechanism for them to get some justice, and it's hard to fault them for that. With that said, we are seeing a lot of activity, legal activity around the ADA in absence of clear technical guidelines. Along with those technical guidelines, we also need implementation standards, when the ADA first passed it did not require every building to immediately be accessible. There were time lines. Maybe by this particular date, it needed to be accessible or next time you renovate the building, if you were a small business, or say running the business out of your home, you didn't have to put in a wheelchair ramp but if suddenly you reached a certain number of employees, now there were technical requirements for physical accessibility. That was helpful to implement those requirements over time, and provide something that was reasonable but also supported accessibility over time. We don't have any of those technical or implementation standards yet defined for the web. It is a bit of a wild, wild web, where we are seeing a lot of this driven by legal action, which I'm sure is probably driving factor for many of you to be listening today.
Most of the places where we see this legal action are in areas where there is clear inaccessibility. There is clear noncompliance with Web Content Accessibility Guidelines. It would be hard to justify that there is not discrimination occurring if people with disabilities are having significant difficulty with the a website. If you are doing 90 in a school zone, the officer has a pretty good case against you, even if there is no speed limits signs. I think that is the reality in most cases, but we are seeing some cases that are maybe, maybe more trivial, maybe where there is difficulty for them to document or justify the discrimination has occurred.
So, our next slide, it brings up the question of, ADA compliant, and what that actually means when it comes to web content. I hear that all the time. People tell me I need to make my website ADA compliant. It doesn't mean a lot. It doesn't mean nondiscriminatory but in absence of those technical guidelines, it's hard to know exactly what that means. Or approach, all of our goal should be to make things work, to make them accessible, to make them reasonably accessible to those with disabilities. I think we do that, then we are in a good place, despite the ambiguity of the law currently.
Slide 24, a couple other things regarding some legal requirements in WCAG 2.1. We have seen the first settlements of lawsuits under the ADA, that have now referenced version 2.1 of those guidelines, because they are now the standard, international standard for web content. We are starting to see ADA processes that are requiring and referencing 2.1, again there is nothing in the law to keep them from referencing any guideline whatsoever. We are starting to see those. Again that is great because 2.1 does help support much better accessibility. In the State of California there is a state statute that will require 2.1 compliance for state agencies and other state entities as of July of this year in the EU, there is also a standard that would require 2.1 conformance for new websites by September of this year and all websites September of next year, September 2020. Those are just a few things in regards to the newest version of the accessibility guidelines.
Slide 25, a few thoughts about minimizing risks and things that you can do to, if you are concerned about legal action, you are concerned about complaints and processes under the ADA. The first one, make your stuff accessible. If your users are having a great experience and not encountering barriers, that is going to be very difficult for those processes to have any grounds. Make things work, that is the biggest thing. You want your content to be accessible to your users. Also very important is to have a policy and implementation plan in place, have a well-defined policy that outlines your goals, your objectives for accessibility and a plan to get there, it may not be perfect right now and that is okay. But having a plan in place to help you get to better accessibility and compliance is really critical, not only to your own success, but it can help minimize the impact, if there were to be a complaint or lawsuit, if a lawyer knocks on your door or the office of civil rights receives a complaint, if you have a policy and a implementation plan that is reasonable, often they will say, looks like you have a plan, please carry on. If you don't, these will be defined for you. You will have technical requirements and time lines defined for you and often those are going to be much more difficult and shorter time lines than maybe you would have defined for yourself.
Address automatically detectable errors. Use evaluation tools, such as wave which is a tool developed by us here at WebAIM, to check your site for things that a computer can detect. Detectable errors only represent a small portion of the total compliance throughout, tools are limited in what they can tell you. But there are many out there, including those that are filing lawsuits that are simply using automated tools to look for errors. They then equate detectable errors with discrimination and use that as justification for complaints and lawsuits.
Addressing those automatically detectable errors can provide a bit of a barrier there, a way to minimize some of that initial risk. And, it's going to make your content more accessible. A tool can tell you something is not compliant, if there is a accessibility issue, it's generally representative of a notable end user issue, something that impacts users. So fix it. It will make your site more accessible.
Slide 26, I'm going to go through these quickly, get into more of the technical aspects of accessibility. I may skip a few slides here for sake of time. I want to make sure that we leave plenty of time for questions. I want to cover some of the how-to, how do we start to implement accessibility, what are the considerations, how do people with disabilities access and use the web. I want to talk about auditory disabilities. The general approach here is to provide captions and transcripts. Provide captions for video and live audio and provide text transcripts for all audio content. The captions are the text that appear on screen, as it is spoken. The text transcript is a written version of the spoken information, and it will include any other important content from that media, maybe things that are visual only, such as who is speaking, identifying the speaker. Maybe if there are, is text that appears on screen that is not verbalized, it would be important that that text be captured or other visual content be captured in a transcript. Maybe also in the audio only information such as explosion or laughter or background music, that is relevant or important to the content, you want to put that in the descriptive text transcript. The idea is that the user can get all of the content of the multimedia by reading that transcript without having to engage with the multimedia itself, especially if they can't see or hear or both see or hear, that multimedia content.
So straightforward, at least in regards to what is required, and what helps support accessibility. Not so easy to actually do.
Slide 28, we outline some transcription methods. This is by far the most difficult and expensive aspect of media accessibility is generating text from the spoken word. Three primary methods for this, you can type it out, that can be very accurate, it can be inexpensive to pay somebody to type out what is spoken but it's really slow. Few people can type at the speed that people speak. So it's going to take a long time to generate the transcript using that method. The second approach is stenography, using the stenograph machine like a court reporting machine, that allows the user of the machine to type phonetically and very quickly at the same rate that people speak. This can produce very high quality captions, and transcripts, and can do that quickly but it comes at a cost. You have to hire somebody with that technical expertise, typically outsourcing. There is also a newer approach for transcription that uses something called a shadow speaker, a which uses voice recognition technology and repeats into the well trained voice recognition software on their computer everything they hear in the multi-media or even in live events, webinars, broadcast, conferences, they can listen and repeat back into the software to generate that highly accurate text, basically in realtime. That is another approach. Again, very quick, high quality captions for the most part, but expensive, because you have to pay somebody with that expertise.
The third approach is automated captioning, so this would use automated voice recognition technology like YouTube, you can upload a video, it will analyze the audio and generate text from that. The primary issue with automated captioning is, always, quality.
The next slide, you can see there is some captions on this video stream, and the captions read, is officially tomatoes it's prisons rations? He look for it. All right, it's gibberish, it doesn't make sense. These are automatically generated captions from analyzing audio. They can be wonderful, the quality can be rather high, with very clear audio, no background noise or music, well enunciated English, the captions can be pretty good. Anything other than that, the quality degrades quite quickly. This can be very quick, almost realtime, it's free, these technologies are free at least as far as the technology itself but the quality is the issue. In designing and development, we talk about the role of two-thirds, where you can have cheap quality or fast and you can only pick two, all three of those techniques for transcription fall into one of those three categories, you can never get all three. Automated captioning, via something like YouTube, can be a good start, if you then go back and manually curate those captions, fix the mistakes and improve that quality.
Those are the techniques for users with auditory disabilities. There are a lot of additional benefits, however, to captions and transcripts, that extend beyond just accessibility and I'm sure that probably everybody here has benefited from captions or transcripts at some point in time. For instance, noisy environments, in airport or sports bar, seeing the captions makes that accessible, or quiet environment, you are in a library and you want to engage with a video having captions on screen allow that to be accessible, without hearing the audio. These make the content of media searchable, not only search engines but also end users, they can be translated into other languages, if the language of the media and the language of the listener are not the same, primary language, having those captions can benefit understanding and learning for uses with cognitive and learning disabilities to see the text on screen or in a transcript, can be very beneficial. In fact studies have shown that it's beneficial to everyone, having those captions on screen help everyone with understanding, retention, and remembering the content in multimedia.
For users with low vision, this is a very significant audience, low vision generally being defined as vision that cannot be adequately corrected with glasses or contacts. There are a lot of different types of low vision. Generally we think of users that just need larger content, where it's a visual acuity thing. But there are a lot of other types of visual disabilities, such as light or contrast perception, where you need significant contrast to be able to see things. Some users are negatively impacted by too much contrast. There is a color perception, where colors may not be discernible, certain color combinations can be difficult to see. Obstructed primary visual field of view, or tunnel vision, where maybe you can only see a small portion of the screen. Tremors in your eye, things like that. Primarily we think about enlarging content. This is a slide from a screen shot from Amazon, at 100 percent, on slide 33, we enlarge that to 200 percent. It is quite a bit larger. We have found from surveys we have conducted that about a third of respondents with low vision don't enlarge web content at all, or at least very much, maybe if you have tunnel vision for instance, making the content larger makes it worse. You can see less of it at one point in time, with a small visual field of view, it may actually be advantageous to decrease the size of some content. About a third of respondents indicate they enlarge content to about this size, to 200 percent which is quite large when you see it.
Slide 34, about a third of respondents enlarge content much much larger, to up to 400 percent or even larger than this. This is 400 percent on screen. Some interesting considerations as content is enlarged by the end user. One is the use of text within images, as text is enlarged, it becomes more pixilated and blocky, a little more difficult to read and perceive that text as opposed to true text or real text within a page. This is something that the accessibility guidelines cover, they say if you can make, get the same visual presentation by using real text as opposed to text within an image, then do that. Use real text. There are a lot of additional benefits to using that real text as opposed to text within an image. It doesn't always make sense. Something like a logo, yeah, you may need to put text within a graphical logo but you want to help ensure and test that as that image is enlarged, that it maintains its readability and crispness of the text.
Slide 36, provide sufficient contrast. This is something that is important for users with various visual disabilities, but it's important for everyone. We all struggle and have difficulty with content that has insufficient contrast. This is interestingly, I think it's pretty safe to say that this is the most pervasive accessibility issue on the web, at least it's the most common detectable failure with Web Content Accessibility Guidelines, is providing insufficient contrast. At WebAIM, about two weeks ago we released the results of a analysis of the top, the home pages for the top one million websites. We, using automated tools, analyzed a million home pages. We found a lot of interesting information, mostly that there is a lot of accessibility issues on the web, and low contrast was by far the most prevalent issue that we identified, present on 85 percent of pages, had text that had insufficient contrast.
How do we know what are some considerations here, one is to understand that the user has ultimate control over the way your content appears. They can override your text colors, they can turn on high contrast, if there are certain color combinations that they need to best perceive and view your content, they can override your colors. Your design is not the design that everybody will see. You want to design your pages to be adaptable and flexible if the user adapts the content or changes it, you want to be flexible and ensure that your content maintains its accessibility as the user customize it to their needs.
Slide 38, if you want to know where you are at when it comes to compliance, for text, contrast, you need to implement this basic formula that is defined in the Web Content Accessibility Guidelines. No, you probably are not going to be doing this complex math. But it is important to know that there is, there are measures for contrast. Web Content Accessibility Guidelines has this formula which based on a foreground color and background color will generate a contrast ratio. They then define thresholds based on that ratio for pass or fail states. There are other considerations in there. But know that there are metrics for this. You don't want to be doing this type of math. But there are functions for measuring sufficient contrast.
Slide 39, this illustrates that using that formula, if you had white text on a black background or black text on a white background, the contrast ratio was 21 to 1. That is the highest possible contrast ratio. This does not necessarily mean that this is best, I mentioned before some users can be impacted by high contrast, too much contrast, especially with modern displays, that are very bright and have dark, darks and very white whites, having too much contrast can impact readability. It can also cause? Users with dyslexia to have additional difficulty, dyslexia is not a visual disability, it is a cognitive processing functioning thing where letters and words can get jumbled and mixed around. With too much contrast, it can cause like halos or floaters around the text, which can aggravate that condition and cause the impacts of dyslexia to be enhanced.
You might want to consider that, maybe a slight off white or very dark gray foreground color could maybe be a little bit better. The guidelines do not define a maximum contrast threshold. They don't consider that at all.
Slide 40, this outlines what is required at level AA, within those guidelines. It requires a contrast ratio of 4.5 to 1 for text, there are examples on screen of gray and purple text on white, red on yellow, those are all examples of text that is exactly at that 4.5 to 1 ratio, which is the minimum required at AA. We have a lower threshold for large text at 3 to 1, large text is defined as 18 point which is 24 pixels or larger, or 14 point which is 18.6 pixels or larger, maybe as if it's big or big and bold, it doesn't have to be as, doesn't have to have as much contrast because it's big and bold.
You can use tools, slide 41 outlines a tool that we have developed at WebAIM, where you can put in a foreground color, a background color and it will do all of that math for you. It will indicate where those color combinations align with the accessibility guidelines. Use these types of tools to make a lot easier to know where you are at.
Slide 42, a couple notes about WCAG 2.1. 2.1 adds new things to 2.0. It doesn't change 2.0 but adds new requirements. One of the new requirements in 2.1 is sufficient contrast for nontext elements. 2.0 only applies to text and text within images. This requires a 3 to 1 contrast ratio for user interface components, so things that the user might interact with and see that convey meaning, that would also include keyboard focus indicators as you hit the tab key, the browser will draw a outline or bold, you want to be able to see that with sufficient contrast. Also requires sufficient contrasted elements as they are being interacted with. If you hover your mouse over a he will I want it still needs 206 sufficient contrast in the hover state -- also needs to have. Also graphical objects, icons, images, things that convey meaning. The interface component would be a border of a text box, you want to see where the text box is at. It covers the checks within the checks box, important for you to know whether the graph box is checked or not. Graphical objects includes Facebook, Twitter icon, things like that that are more common in modern web design than they were in the past. This is a nice gap that has been patched by WCAG 2.1 to support better accessibility of these nontext elements. It is at a minimal contrast ratio, 3 to 1 is pretty low contrast. It is the minimal required for many users to see but it does define the minimal threshold. You probably want to go beyond that, have better contrast for better readability and usability because this is not just a disability theme, it's something that impacts everyone.
Okay. Slide 43, a few words about color reliance. I mentioned colorblindness or color deficiency as it's more technically called which is difficulty in differentiating between certain color combinations, there are many different forms of colorblindness, the most common is a red green color deficiency. It doesn't mean the user can't see red or can't see green. It means that certain shades of red and green can be difficult to differentiate when they are used together. In this case, we have a list of mushrooms, the green mushrooms listed here are okay to eat. The red mushrooms will kill you, visually they all appear the same. You are seeing the list as it would be seen by someone with the most common form of red green color deficiency. I'm not sure if you know mushrooms well but you might pick for yourself which of these you might take a chance at eating, assuming you like mushrooms at all. Slide 44 shows the actual results. The middle three are in green. This is a case of color reliance. This does not suggest that you shouldn't use color, that you can't use color. You can. You can use color. It is great for accessibility. It is great for usability. You want to ensure that you are not relying on color to convey information or meaning.
There are a few things that can be done to adapt this content for better accessibility. You can use icons to visually differentiate those. Other types of styling. You want to consider somebody that is blind is also colorblind, if someone can't see the screen, the color information is also lost. Users can override your page colors and that color information may be lost. There are a lot of people that can be impacted by color reliance.
Slide 45 talks about screen reader users. Screen reader is assistive technology used by somebody with primarily visual disabilities to have text content on a page presented audibilitiy to them, audibly to them. Not all screen reader users are completely blind. Many of them have low vision, and use the screen reader to supplement with audio, where they may have difficulty seeing visually on the screen.
There are some users that have no visual disabilities at all, they may have a reading or cognitive disability where hearing that content audibly allows it to be better understood or perceived than reading it visually on the page.
Slide 46, structure and semantics. When we talk about screen reader accessibility, we want to ensure that we are defining structure, that we are defining meaning or semantics into our page, to enhance accessibility, to better present the content that is apparent visually to sighted users. Things like providing alternative text for images, you want to define, present the content and function of an image in alternative text, for a screen reader user that can't see the image, alternative text would be read in place or as a alternative to that image. Content and function, those are the two key words.
I think this is the shortest treatment I've ever given to alternative text in a presentation. There is so much more to alternative text. I would refer you to a article on the WebAIM site that goes into more detail and nuance when it comes to alternative text, which in many ways is one of the most complex aspects of accessibility. Not because it's difficult to implement, but because it's so subjective and we walk through several examples in our article, to give you a better understanding of how to generate and provide proper and equivalent alternative text.
Using headings appropriately, so big and bold text, we use visually to identify the structure of the document, defining those headings appropriately, in the code of your page, the first level heading for the main content heading of the page, second level headings or H2 elements in html for sub headings and third level headings below those, those facilitate screen reader understanding of the content and also navigation within the page, screen reader users very often, in fact it's one of the most common mechanisms for navigation in the page, is to navigate by the headings within a page. So very important for accessibility.
You can define page regions or sometimes called landmarks, header area of the page, footer, main content area, navigation area, things like that can all be defined semantically. Those can be identified and navigated by a screen reader user, visually we come to a new page and parse out, here is the header, footer, good stuff, main content, navigation, search over here. We visually parse this page. Then we build that mental model of the structure of the page and every subsequent page that we come to, we don't reread the navigation or header or search. We jump right to the good stuff. If we are looking for navigation, we know where it is, because we built that model.
You can provide that same functionality to someone who can't see the page, just with a little bit of code defined within your Web Page.
Other things important for screen reader accessibility associating label text to form inputs, so if you see the words first name in a text box next to it we make a visual association. Someone that is blind can't make a visual association between that text and the input. But we can add a code under the hood and almost all these things I talk about are under the hood of the page, they are in the code, they are transparent to the visual design, transparent to the visual interaction but vital for nonvisual accessibility. We can provide code that associates that text to the form input. With the data table, we can stand up or down left or right in a data table to know what a particular piece of data is, because of the visual association with its column headers and row headers, a little bit of code can provide those same structure only in semantics association, for a screen reader user. Provide a descriptive page title, that is the text that shows up in the tab at the top of the page that is the first thing read by a screen reader, useful to so that the reader knows what the page is about. We can define document language, English, Spanish or Japanese, for multilingual screen reader users it ensures the page is read in the proper language. It is like nine or ten characters in our html code, but under the scenes, totally transparent but really important for optimal accessibility.
Slide 48, a few things on the topic of operable or operability. Ensure that functionality is available via the keyboard. If I can't use a mouse or touch pad, I want to get to everything on the page, perform all of the functionality that is available to mouse users, simply using the keyboard. It's efficient, that I don't have to hit the tab key 600 times with the stick in my mouth because I don't have other mechanisms to interact in the page. Also ensure that keyboard users can tell where they are at within the pages, you hit the tab key, there needs to be a visual indicator, and the browser does this by default. We need to make sure we don't turn it off and break the as users interact within the page.
Slide 49, couple other things, with operable, make sure we provide meaningful link text, avoid click here, more, continue, things that by themselves may not make sense. Visually we can usually see those links and we can stand before or after that link to figure out what the link is about. Visual overhead to that, but it's difficult for someone who can't visually scan the page, if they are using a screen reader it is difficult as they navigate through the page or read the link in the page, they might hear click here, click here, that is not helpful. We can modify link text to be descriptive of its function and purpose. We can facilitate keyboard accessibility by providing a skip link or skip to main content link within the page. One of the first things in the page allows quick access to bypass the header and navigation and search and sidebar, whatever and get right to the good stuff within the page.
Slide 50, deals with understand ability. I'm going through those POUR principles, of the guidelines. Consider reading the whole legibility, using good design, these are things that can be hard to measure, simplifying, being consistent. These are not defined well in the accessibility guidelines but they are common sense, which sometimes isn't that common on the web. But they are really important for people to be able to use your content, if they can't understand it, it is not going to do them a lot of good. Be careful of animation, often advancing carousels like those animating frames on home pages which automatically advance, auto playing video, those can be hugely impactful for a lot of people, especially those with certain types of cognitive and learning disabilities where they can be significantly distracted by animating content. They can impact keyboard accessibility, screen reader accessibility within a page. Do use ability testing with users with disabilities. Take a step back and as you are doing your testing, include users with disabilities as part of the process, it can help you identify often these aspects of understandability, that can be impactful.
Slide 51, a slide, a photo of a courthouse down in Florida, if you can see this image, you may notice something interesting about the accessibility of this entrance. On the left-hand side of the image is a ramp. The ramp deposits the user in the landing in the middle of the stairs. On slide 52, there is a slightly different view of this ramp, the very long ramp that goes to the landing right in the middle of the stairs. You might think of this and say, did somebody consider accessibility when they built this entrance? I would say yes, they did. They built a ramp, a very long expensive ramp. But did they really consider accessibility? Did they really consider the end user experience? No. Maybe they had a checklist that said wheelchair ramp. Check, yep, we built the ramp. But they didn't consider the entire user process. Imagine if you were a wheelchair user and you come up this ramp to suddenly find that you can't actually get into the building. This ramp is worse than no ramp at all, sometimes accessibility implemented partway or incorrectly can be worse than the whole accessibility effort at all. We want to make sure we are doing this correctly. Most of all, that we think about the user processes, flows, from beginning to end, can a user complete a entire process. Those are things that can be detected via user testing as opposed to accessibility testing. Accessibility testing often looks at instances of inaccessibility. Very often it's checklist driven. Do we have a wheelchair ramp? Yes. Process or test this, user testing is can the user in the wheelchair get into the building. The results of that can be very different from just accessibility testing.
You want to think about that. Sometimes those processes or flows that last step, that last page, probably won't show very high in your site analytics. It probably isn't a highly visited website, but very important to the success of the entire process or flow.
Slide 53, shows photos of two other entrances to buildings. On the left is a wheelchair ramp. There is a wheel chair sign or placard next to this. On the right is a ground level revolving door. There is accessibility built into this revolving door. There are a couple things, one, there are sensors within the door, so if you are moving very slowly through this revolving door, it is not going to force you through. It will slow down and move with you. So you are using the walker or crutches, have a small child, it will slow down and move with you. In this case there is a button on the right side of the entrance, if you activate the button, the door will stop and visually the right-hand side of this revolving door is folded open. If you are in a wheelchair, you can go directly in and through that entrance into the building with this revolving door in this state.
Both of these entrances provide accessibility. I would argue that the one on the right probably provides better accessibility. At least a better approach to accessibility. The wheelchair ramp does provide accessibility and there are additional benefits to it, like I can push my kids in the stroller up there, the delivery person can use that ramp. But what it suggests is, if you have a disability, this is your way of getting into the building. Right? You go over here. In this case, the ramp, you can visually tell the ramp was added after the fact. The color doesn't match the rest of the building. It juts out into the sidewalk. Maybe it's even more steep than it should be. This is something that has been added on to provide accessibility after the fact, as opposed to the entrance on the right, it has been designed for accessibility from the get-go. Accessibility has been considered and integrated directly into this entrance.
Yes, there is an additional cost, to the accessibility of a ground level revolving door. But the vast majority of that cost is the decision to put in revolving door, it is not accessibility but by considering accessibility you have one entrance that anybody can use the same way as opposed to the wheelchair ramp which is you go over here, a restaurant may have a wheelchair ramp and it's around back and the user has to go through the kitchen to get to eat. Is that a equitable experience? No. It is not. Sometimes that retrofitting is a reality. Sometimes you have things that are not inherently accessible and you have to bolt on that accessibility. It is always going to be difficult, always going to get expensive and never going to be as efficient as considering accessibility from the beginning, through early December I know and development -- design and development. We end up with better things, better for everyone because the accessibility is inherited naturally into that environment. That is where we need to deal with the web. When the ADA first passed we had ADA architects that, a architect would design the building, your ADA architect would come in and say this doesn't work, you have to put in a ramp here and these doors have to be wider. We ended up with ugly retrofits for accessibility. If you learn to become a architect today, you learn how to design an accessible building because it's your job. It's part of what is required of you, is to build in this natural accessibility. We see fewer ramps. We see more ground level, naturally accessible to everyone entrances. We need to get there on the web. We need the architects of the web today to understand that accessibility is their job. It is part of what they need to do and implement as opposed to something that is addressed after something has been developed in which case, we can maybe make it compliant, but it is not going to be nearly as truly accessible of an experience.
Okay. A little bit of a soapbox there, about the concept of accessibility and optimal approaches to this.
Slide 54, I mentioned earlier the wave tool. This is something that would be useful to you in your accessibility efforts, it's found at wave.WebAIM.org. It's on-line free tool. We have Chrome and Firefox extensions, to allow you to do evaluation directly within your browser. If you want to get a good sense of detectable issues, where you are at when it comes to accessibility, this can be helpful. Keep in mind tools are quite limited, they can't tell you if your site is accessible or compliant. But they can identify apparent things and because we know that human testing, human evaluation is a vital part of accessibility, wave has been designed to help facilitate that human accessibility testing. We help underline things that can support your own testing within the page.
Okay. Slide 55, I want to end with this quote, it reads for people without disabilities, technology makes things convenient, whereas for people with disabilities, it makes things possible. Keep in mind the great power of the web, the great impact of the web, that it has on people with disabilities. Go out and make things accessible. It's more than just convenience for many people with disabilities. It is their reality. It makes things possible for them. With that, I will say thank you, and we will go to any questions that you might have.
Peter Berg
Excellent, thank you, Jared, for all of the great information, lots of information there. For those of you participating in the webinar room, you can continue to submit your questions in the chat area. Once you submit the question, you do not see it. It is viewable by us on this end. Natalie at this time, I'd like you to give instructions again for those on the telephone if they wish to ask a question.
Operator
Certainly. To ask a question over the phone, please press star 1 on your telephone keypad.?
Peter Berg
While we wait to see what questions we get there, Jared, this is my question, big picture perspective, what do you see from your experience in working in this arena as the biggest barriers? I'm not talking about the actual barriers on a website, but the bigger picture, is it lack of awareness? Is it lack of experts in the arena? Is it the lack of educating people in schools who are in computer science programs, what are the biggest barriers from that larger picture perspective?
Jared Smith
Yeah, that's a great question. It is a big question. I could spend another hour and a half probably talking about that.
All of the things that you listed I think are barriers. They are challenges. If you had asked me this question three weeks ago, I probably would have said awareness. That is really what I've generally always said about this, is that awareness is the big thing. And certainly, I think it's a big consideration. There is a lot more we need to do with awareness. But I think awareness is increasing. There are a lot more people that are interested in this topic. We would not have seen 180 people on this webinar a few years ago. No way. So there is a lot more awareness.
I think as that awareness has increased though we have not yet seen substantive change. There are pockets of accessibility, there are certainly things that are happening, but our evaluation of the million websites found significant and pervasive accessibility issues, all over the web. 98 percent of pages had detectable compliance failures. An average of 60 compliance errors, or end user issues, per home page. Imagine being someone with a disability and on average, encountering 60 barriers on a home page. That is the reality of the web today. That is a little discouraging.
I think my answer today would be lack of support, that I think more developers designers are aware of this, but it's not being emphasized by leadership. They are not given the resources necessary to actually implement accessibility. The priorities are fancy design, newer technology, innovation, and accessibility very often is not one of those priorities. And it's reflecting in the web every single day for people with disabilities. I think my answer to that is shifting a little bit from awareness, and we need to do more awareness but awareness doesn't do good if people are not empowered to implement accessibility.
Peter Berg
Right. Great answer. So, you went through your presentation, if you were starting at a, just hired by a state or local government or a business and it was your job to address the content of their website, what would be your roadmap? What are the starting points for businesses or for government agencies to get the process rolling to ensure their content is accessible?
Jared Smith
Another big question, that is a good one. As you can see there is a lot to accessibility. If you approach it simply as a technical thing, there can be a lot, it can be overwhelming all the technical things that need to be implementedded for accessibility. I wouldn't start there, those are important we need to implement accessibility but starting out at a new place, especially if there was not already a strong emphasis on accessibility, I would try to make it real, make it personal. Demonstrate the page in the screen reader, even better, allow a user with a disability to talk about their experience, to demonstrate it for themselves, to make that really personal. So that as an organization, you have a better understanding of the impact that this has, not on people but on this person. And people like him or her.
I think that is where we get a lot better motivation, when it becomes really real. Then transition that into education. People ask us about the cost of accessibility all the time. How much more is it going to cost to make it accessible? And the cost of accessibility really is a function of education and knowledge. If your architect designs that inaccessible building and says how much is it going to cost to make it accessible, it is going to be a lot. You are busting down walls and bolting on elevators and wheelchair ramps. An architect today, they don't, you wouldn't order a architect and say I want to build this building, how much more is it going to cost to make it accessible, we just don't approach physical design that way, because it's their job, it's part of building a building.
For the web, that additional cost of accessibility is truly going to be a function of the knowledge of the practitioners that are designing and building it. So transitioning from that awareness and that motivation to how do we do this, how do we do it effectively is important. We see a lot of people that are, have motivation for accessibility that get it wrong, and that can be a little bit difficult, like the wheelchair ramp that goes through the landing in the middle of the stairs, perhaps well-intentioned, but misinformed. So yeah, moving to that knowledge, as we look at our analysis of the million pages, the vast majority of the issues that we identified fit into a few categories. In other words, simply attention to those low contrast, missing alternative text, form, saysably identifying the document language -- accessibly, those few things would address millions of barriers for people with disabilities on the web. Basic foundational principles of accessibility can go a long way.
Peter Berg
Great. Natalie, do we have any questions on the phone at this point?
Operator
We do. Our first question, your line is open.
Caller
Yes. Jared, thank you for all your work, I appreciate your presentation. I wondered if we can get a 30,000-foot view, opinion on for a agency that needs to be Section 508 and WCAG 2.0AA guideline compliant, what do you think about WordPress or do you have specific examples of how small agencies can help to make their website accessible?
Jared Smith
Yeah, oh, yes, thank you for the question. There are a lot of good models out there for good accessibility. You mention WordPress. WordPress supports, I think good accessibility. That is something we analyzed in our million page study, and found that the presence of WordPress didn't really have a positive or negative impact for overall errors that were detected. WordPress can be a good choice. There are a lot of others out there, the tool itself is not going to provide the accessibility. It is what you do with that tool, and the design and development. But most of all, I would go back to the things I talked about a few minutes ago, having as a agency, having the commitment to accessibility. We are finding for some of the agencies out there that really have a strong commitment, it is a business differentiator for those. There is lots of demand for design firms that have good accessibility chops and they are finding market opportunities there, and that good training, that good education as a part of that, to make sure that as a firm you are absolutely implementing accessibility correctly and being a good model for accessibility.
Peter Berg
Thanks for the question. I'm going to do a follow-up question, that ties into this. You mentioned verify and, what did you say? I took a note here. Trust and verify. You are looking at, are there resources, is there, what kind of questions can folks ask to evaluate, I mean like you would with any contractor, you want to make sure that your contractor, if you are putting in a new toilet for you or whatever, you want to make sure that they know what they are doing and they are complying with building code or plumbing code or whatever. Are there resources, are there questions that can be asked, using a VPAT, is that a tool that a entity that does have compliance obligations, that they can ask and evaluating whether or not a vendor is appropriately knowledgeable?
Jared Smith
Yeah, you know, this is a pain point when it comes to procurement, that many that are evaluating office in procurement don't have accessibility expertise to evaluate accessibility -- offers in procurement. Good documentation would be helpful, VPAT or other documentation of accessibility is great. I would generally suggest if all that documentation says is passes, passes, passes, there is no indication of inaccessible, inaccessibility, that usually is [inaudible] full compliance with the accessibility guidelines can be difficult. It can take a lot of effort to get there. For many, probably the vast majority of products that are out there they are not fully compliant. You want to look for areas where there is documentation of noncompliance. Ask questions about the impact of those areas of noncompliance. Ask about their testing methodologies, that can be insightful. What did you use specifically to do this testing? If they say, Wave or some other automated tool, that is not going to be sufficient. They had to have done more manual testing, probably using the assistive technology, screen reader testing, what is their knowledge and familiarity with the accessibility guidelines. Then stemming from that, I would ask them about their accessibility support. What are they going to do if it's not accessible? I would build that into the procurement. We are seeing a lot more of that, language that has teeth. If you sell us something and you declared it to be accessible or compliant, and we find out that it's not, you are going to make it right. That is something that is built in to procurement, we are seen, we are seeing indemnity language, that says if we are sued, we are getting a complaint over this, you are going to cover our expenses to defend that, and to make it right. Those are additional things. Ultimately though, would need procurement mechanisms for better evaluation. There are some efforts afoot to better define a testing and for procurement people, and sharing of that information in research, so every entity doesn't have to evaluate the same tool individually, but that information can be shared across, say organizations, higher Ed institutions, things like that, so there is a central body or repository for that accessibility and knowledge.
Peter Berg
Great. Natalie, do we have any more questions on the telephone at this time?
Operator
We do. Our next question. Your line is open.
Caller
Yeah. I had a question. Once you find the management system and you got a WordPress or whatever that might be, how, is there a special code that we can use to [inaudible] Google more prominent as a accessibility site.
Jared Smith
Good question. The question was, if you choose your platform, something like WordPress, is there a way it can be more visible because of that accessibility. Not really directly. Something like WordPress, if you were to publish or create your own theme there are ways to mark those themes as accessible and that can, other people searching for WordPress search for accessible themes. As before trust and verify, test it out for yourself but most of that, those benefits come from search engines happen organically because of that accessibility, making it more machine readable, providing alternative text, labels, good headings, structures, identifying regions for your page, those are all things that support better search engine friendliness. I'm not going to say search engine optimization but our clients found benefits come organically by providing good content. What Google is looking for, they consider traffic and relevance of that content. If your content is good, if it's accessible, you are going to get content you are going to get cross-linked, those are all things that benefit accessibility. There is some evidence that implementation of accessibility techniques can automatically provide some sort of search engine boost. Google seems to have some metric that says, there are techniques implemented into this site that are supportive of accessibility. Therefore, somebody must care. They have implemented, they have done effort for accessibility, therefore we are going to provide them additional search engine benefit in ranking because of that. That is not something that you have defined. It is not like you add a tag that says, hey, Google, we are accessible, but the implementation of those goods, structures, semantics and good content and everything else I talked about will bring those benefits.
Peter Berg
All right, great, thank you for that question. The use of social media, where businesses or state and local governments embed social media, a Twitter feed for instance in their home page or website, what are potential accessibility issues when you are bringing in a third party into your website?
Jared Smith
So I would first indicate that simply because it's third party embedded within your site does not get you off the hook. Right? The courts have clearly stated that in embedding something like a Twitter feed that is still part of your page, that is part of your content, and thus you could be held liable for the accessibility of it. So it's not just get out of jail free card there because it's third party.
Those things can pose issues. We need better accessibility for those types of components and widgets. We need to put pressure back on those third party providers to support better accessibility. As far as if you have these things today and what you can do, you can implement mechanisms for users to bypass those. Very often native clients and leaders might be more accessible in the embedded versions for instance, embedded YouTube video, allowing the user to go directly out to YouTube to view it is often a more accessible experience. Viewing a Twitter, your Twitter feed on the Twitter website or within their end user client, often is more accessible than an embedded feed. Not saying you can't do those things. You want to consider test accessibility but very often provide mechanism to get back to view it in another way can be a good strategy?
Peter Berg
Great. Thank you very much for all of that information. Unfortunately, we are near the bottom of the hour, and we are quickly running out of time here.
If you submitted a question or still had a question, I encourage you to reach out to Jared and the folks at WebAIM, as well as reaching out to your regional ADA center for additional information.
All of Jared's speaker bio is available on ADA-audio.org, so you can read his full bio on that page. I want to thank Jared for joining us today, not just for the 90 plus minutes he gave us today, but for his time in prepping and doing a test session with us to get this session off. Our next session will be April 16, we will have a session titled, ask the EEOC, for those of you that have been with us for any period of time, you will recognize the name Sharon renert, she is a attorney with EEOC within their ADA division. You can submit questions in advance for that session, you can get registration information by visiting ADA-audio.org. Today's session has been recorded, is being recorded. The archive will be available, the audio archive will be available within 24 hours and will get a written transcript posted and edited within a couple weeks time. You can check back again to ADA-audio.org. If you have questions about the ADA audio conference series give us a call at 877-232-1990.
I thank everyone for joining us today. Thanks to Jared. Take care, everyone. Have a good day.
Operator
This concludes today's conference call. You may now disconnect. Have a great day.
Services Provided By: Caption First, Inc.
***
This text, document, or file is based on live transcription. Communication Access Realtime Translation (CART), captioning, and/or live transcription are provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.