Modern Web Accessibility - revisiting fundamentals and looking at new challenges

Modern Web Accessibility - revisiting fundamentals and looking at new challenges

Thursday, January 19, 2017

Announcer

00:05 - >> I am an accessible technology consultant for the Pacific ADA center and the accessible technology webinar series is sponsored jointly by Great Lakes ADA center, Pacific ADA center and the ADA National Network. We are delighted to have you join us. The session is being recorded, as we mentioned. It will be archived. You will be receiving a link to that archive as soon as it is available, probably within about 24 hours. You will also be receiving some handouts which will be E-mailed to you along with an evaluation survey. Please do take a moment to fill in the survey. We do use it and rely on it extensively for planning our sessions. Your comments are always greatly appreciated.

00:52 - Today we are going to be talking about accessible web design which is something that is obviously near and dear to all of our hearts, and Jared Smith, the associate director of WebAIM is going to be joining us to do that. He is a highly demanded presenter and trainer and has provided web accessibility training to thousands of developers throughouted the world, has a degree in marketing and business education, Master's degree in instructional technology and over 16 years of experience working in the web design development and accessibility field. We have had the pleasure of having Jared with us before some years back, we are delighted to have him with us again, he brings a wealth of knowledge and experience that is used to help others create and maintain highly accessible web content. With that, very pleased to welcome Jared to us. I'm going to turn it over to you.

JARED SMITH

01:55 - >>

Thank you very much, Judith for the introduction. It is great to be here today, and to talk about web accessibility which I'm very passionate about. I'm from WebAIM, which is the web accessibility in mind project which is based at the center for persons with disabilities at Utah state university. We do web accessibility. I encourage you to check out our website at WebAIM.org, there is a wealth of articles and resources and tools available there to help you in your web accessibility efforts.

02:27 - Today I'm going to, I talk about modern web accessibility and many of the aspects of accessibility that are modern are the same things that we have been dealing with in the 19 years that WebAIM has ...

02:44 - (silence).

02:46 - Has existed, and then addressing web accessibility efforts. Some of this may be new. Some of this will be old. But all of it is applicable to the modern web.

02:56 - (distorted audio).

02:58 - A framework first, it's very important we have a foundation and a framework for what accessibility is and what it does. Some benefits of accessibility, beyond the obvious of addressing the needs of individuals with disabilities, but it does encourage the design and development practices, we have found as people implement accessibility that things become easier, from the development standpoint. Things become easier, coding practices, support, good plain code and efficient processes for design and development. It also supports search engine, maybe not so much optimization, as friendliness, by making your content more compatible with the assistive technologies that individuals with disabilities might use, by making it more machine readable to something like a screen reader that will extract the text content of a website and read it to someone that can't see that Web Page. You are making it more machine readable to search engines. That is another nice benefit of accessibility. Supports internationalization, and good usability. Also supports mobile friendly content. The idea of making your content adaptable to different users, regardless of the technology that they might be using, ensuring that your website still works, supports good mobile friendly content. If I'm viewing the page on a very small screen, say on a mobile phone, that is really not a whole lot different than taking a standard Web Page and enlarging it so that it fits more, fills more of your visible display on a standard computer.

04:41 - The concepts are very similar. We know from the census data that 20 percent of the population has a disability. Of those, about 8 and a half percent of the population has a disability that affects computer use. I think this is really significant. I'm probably preaching to the choir here, but just that number, if you consider it worldwide, that is more than twice the population of the entire United States. Every man, woman and child, two times. That is the number of people that we are talking about here, about 8 and a half percent. At 20 percent we are talking about over a billion people on this planet that have disabilities. This 8 and a half percent of the population is minimal. It doesn't include those with cognitive or learning disabilities, which many have suggested is actually larger than 8 and a half percent all by itself. It doesn't include those with colorblindness and so forth. You might ask what that 8 and a half percent means, is it significant. We have to be reasonable in our implementation of accessibility. We know that you don't have unlimited funds and time and resources to implement into accessibility. Regardless of what the number is, it's important that we recognize we are talking about people. We are talking about humans, individuals, and accessibility can really significantly impact them, especially those with disabilities, because the web is such a powerful avenue for them to access information and to engage in commerce and education and everything else that we do for people with disabilities, sometimes that is the primary mechanism for them to engage in those types of things.

06:28 - I think it's helpful that we view accessibility as a continuum. It means you can always be more accessible. I think that is, for engineers, that is a little disconcerting, the idea that this is something that is never fully done. It's empowering to view accessibility that way, I think, in that you can always improve. You can always make it a little better. It really is a process. And something that can always be improved. I think that is really empowering to accessibility, and it draws the focus back to the human experience as opposed to simply meeting some technical objective or standard.

07:11 - Now, if we view accessibility as a continuum, it is important that we have some measures along that continuum. When someone says my website is accessible, that doesn't really mean a lot. Accessible to whom or accessible to what, level or standard. So we do have guidelines that are measures along that continuum of accessibility. They are helpful for us to know, you know, get a accepts as to what the -- sense as to what accessibility is and what the impact might be on particular users with disabilities.

07:46 - The standard set of guidelines, that are available out there, ones that we would definitely recommend be used and implemented now are the web content accessibility guidelines, version 2.0. These guidelines were finalized in 2008. They are very principles based. They have four foundational principles of perceivable, operable, understandable and robust and I'll be going into a little more depth on those four principles for the next, the remainder of the webinar. There are also three levels of performance or compliance with these guidelines, A, double A and triple A. We recommend generally A and double A as a good standard for ensuring optimal accessibility for most users with disabilities. There are things that may extend beyond those guidelines that are important. This is a good foundational set of standards that we would recommend. It's also the set of standards that is generally required by lawsuits, by federal requirements, things like that, it is also the set of guidelines that has just in the last couple weeks been finalized as the future standard for the Section 508 guidelines for anyone that receives federal funding or within the federal government, that likely will be the technical standard, is A and AA compliance within the web content accessibility guidelines.

09:15 - These guidelines are, can be difficult to understand, and to implement, and evaluate. We do on the WebAIM site have a WCAG 2.0 checklist that can be helpful for you to get the basics of these guidelines and know how to implement and evaluate them.

09:36 - It's important, as important as guidelines are, I think even more important is to really first consider the usefulness of something that you are building. Then consider how usable it is. After that, let's focus on the accessibility principles, POUR principles, perceivable, operable, understandable and robust. If something isn't useful to users, if it's not content that they are going to want to engage with, does it matter if it's accessible, if nobody visits it? We want to make things that are useful. Next we want to make it usable, as they are engaging with it that it's presented in fairly standard ways that it's friendly, it's understandable to them. Then let's move on to the accessibility techniques.

10:22 - Often we will work with clients that want to address accessibility, in a website or platform that has significant usability issues. That is very difficult. You can't fix usability issues only accessibility techniques. You have to focus on usability first and then the accessibility becomes much easier. Another way of saying this is, web accessibility lipstick on a usability pig. That is a phrase that I use sometimes, that I think is very apt. If you have something that has significant usability issues, no amount of accessibility lipstick is going to fix it. You have to focus on the usability first.

11:14 - Now we have over, I think over time, seen an evolution of accessible design, this is something that we see in a very micro, or macro way among clients, among individual websites, among organizations, as they start to address accessibility.

11:35 - Initially, we have things that are really inaccessible and the knowledge I'm going to use is busing systems. The Americans with Disabilities Act first required accessibility for buses, we had people that manufactured buses and the people that ran and administered the transportation systems, for buses, they were saying things like, why should we make our buses accessible to wheelchair users, because wheelchair users don't ride our buses. And of course they don't, because they can't. They are inaccessible to them. We need to be careful that we don't make those types of assumptions. We have heard people say things like, oh, this is a medical school website. I don't have to worry about accessibility. Nobody with a disability would become a medical doctor. Wow. We have to be very careful about those types of statements and assumptions when it comes to the web. I think everyone here is well beyond this stage or you probably wouldn't be listening to me today.

12:43 - Next comes this stage of accommodation. Especially in education, there will always be a place for accommodation. There will always be things you cannot make natively accessible. My voice on this webinar cannot be naturally or natively made accessible to someone that cannot hear. So we provide an accommodation, we provide the accessibility via captions, so that it can be accessible. But often accommodations especially for things that could be made natively accessible is plenty, here is a photo of a forklift type device that is lifting somebody with a motor disability into a bus. That is what we would see early with buses, or even this alternative bus, that was, was sent on special routes to only pick up those with disabilities, and think for a moment about the connotation that comes along with that, and even the term that we tend to use for that.

13:44 - It can provide a better experience than something that is inaccessible but it's not very efficient and does not result often in a very good user experience.

13:55 - Next, along this progression, we see retrofitting. We saw buses that would, initially would use a cutting torch and cut a big hole in the side of the bus and bolt on the side a hydraulic ramp. Eventually those ramps became built into the buses. It worked. It provided accessibility, but there were limitations. It took a long time. It was often an inconvenience for other people on the bus. Generally, one wheelchair user at a time. It was clunky and expensive and difficult. But it was certainly some progress from the earlier stages.

14:36 - Then finally, we have accessible design or universal design. We have a fairly modern busing system here, that has accessibility built in, where the user or the driver can hit a button, the bus will lean, it will lower, it can hit another button, this ramp will automatically fold out and you can enter the bus very easily. This is, has made buses more accessible and friendly to everyone. It is efficient for all users, multiple users with wheelchairs, at one time, can access the bus. This is where we want to get on the web is having things that are naturally and natively built in to the accessible interface that we are providing. It is a mentality and approach that can, is really insightful to modern web accessibility.

15:28 - It is important to note that your site can be compliant, yet inaccessible. You can meet the requirements of the technical standard, even a stringent or extensive technical standard, yet still have accessibility issues.

15:45 - We are always going to favor accessibility over compliance. Focus on the user experience, and use accessibility guidelines to help inform a good user experience.

15:56 - Take this another step, your site can be technically accessible, yet functionally inaccessible. Where we see this a lot with modern web pages and applications, often is with keyboard accessibility. You can make something technically keyboard accessible, you can use the tab key to navigate through that interface, but it is horribly inefficient, the user has to hit that key maybe a hundred times, 200 times, we have seen 600 navigation items, all in the navigation portion of a Web Page before the user even gets to the main content area of the page. It was technically accessible, but functionally a very inaccessible experience for keyboard users.

16:44 - Again focus on the user experience. I'm going to go through our four principles and talk about some of the things you can do to help ensure functional accessibility and a good end user experience, focusing first on perceivable, getting the content to the users' senses in a way that will be useful and meaningful to them. For users with auditory disabilities this will be captions, for video and live audio, and text transcripts for all audio content. Two simple points, easy to understand, not so easy to implement, I suspect for someone or maybe many of you that captioning and transcription is a pretty significant difficulty for you when it comes to accessibility. Fortunately technology is coming along and it's getting better, and there are a lot of resources out there to help with this.

17:38 - For users with visual disabilities, users that are blind or have low vision or colorblindness or color deficiency, there are many different types of assistive technologies that can help users with visual disabilities. Screen enlargers, screen readers, things like that, that can help these users. But probably the most important thing to consider for users with visual disabilities are these two key words, structure and semantics. As the application an content structured in a way that facilitates understanding and navigation of that content, and are the semantics of components or things within the Web Page are they accurate, are they meaningful to the user.

18:27 - This is kind of foundational aspects of accessibility for users with visual disabilities. What are examples of what structure and semantics mean? Headings, probably one of the most important things you can do for accessibility is a good heading structure for your document, we generally recommend 1H1 or first level heading per page. If you, and then subheadings below there, below that heading, that define significant page areas or sections within a document. If you take out only the headings, if you view only the headings of a document in isolation, they shouldn't simply form a outline or Table of Contents for that document and each heading should be descriptive of a section of content. Headings not only help support good understanding of the page visually, when I come to a new big long Web Page, I scroll real fast and I look for big bold text. Based on the size of that big bold text and scanning through that, I can really quickly get an understanding of the content and structure of that document. You can provide via true headings and a good heading structure the same functionality for screen reader users, they can navigate by headings, by heading level, they can pull up a list of headings on the page to figure out what the content and structure and layout of that document is.

19:58 - Headings are very important for accessibility. There are other things you can do to facilitate navigation and understanding of content in a page. You can define regions or landmarks in html 5, we have the header nav, main, footer, and aside elements, that help define significant page areas. In ARIA, which I'll talk about more in a moment, you can define what are called landmarks with banner, which is the same as header, complementary, which is the same as sidebar, content info which is for footer content, main, navigation, search. These define significant page areas and as before a screen reader user can navigate to all of these regions or landmarks on the page, it can pull up a list of the regions, they can jump directly to them. So very beneficial to not only understanding the layout and structure of a page but also to facilitate navigation through and to those particular regions or areas within a page.

21:04 - Very easy generally to implement in most pages is to define these. I would typically recommend using the html 5 elements, and at least right now it is going to be a much better, probably more universal and forward thinking approach than using the ARIA landmarks. With the exception of search. Search is one of these that does not have a html 5 equivalent. Using role equals search on your search build is, any page that has a search build should probably have that.

21:40 - As for semantics, you want to use meaningful link text, avoiding ambiguous links like click here or read more or continue. In isolation as a user of the screen reader, navigates to those links, it likely is not going to make sense. They would have to explore the context of that link to figure out what it means. Sighted users have to do the same thing. When we see click here or more, we have to visually stand before or after that link to figure out what it is or what it means.

22:15 - Alternative text for nontext elements, this is rule number one of accessibility. I could take several hours and talk only about alternative text, I don't have that amount of time. But what I do recommend is two key words to remember, content and function. What is the content of the image, and has a function, you can click on it, ensuring that that is conveyed via the alternative text. We have an article on the WebAIM site that goes into the nuance and details of alternative text. In many ways alternative text is one of the most difficult aspects of accessibility, not difficult to do from a coding standpoint but because of the nuance and subjectivity of determining what is good, equivalent alternative text.

23:07 - Labeling form controls, when you come to a form and you see a text box, you know what the function of that text box is based on the adjacent text. You make a visual association, someone that is blind can't make that visual association. So we provide an explicit association between those items in our mark up. This is the label for this particular control.

23:33 - Button values, this is something that we are seeing more and more, especially in web applications, are buttons that do not have any descriptive text that define what the function of the button is. Often this is because background images are used to present a visually graphic for the button, but there is no text present to be presented to a screen reader user. So make sure that all of your buttons have descriptive text. If you don't want the text to be visible there are ways to define the text so it does not appear visually but still will be read by a screen reader.

24:10 - We can associate data cells to row and column headers. If you think of a grid of data in a data table, visually we can scan up and down left or right to determine what a particular piece of data in that table is based on its row and/or column headers. Someone that is blind can't make that visual scanning and association. We as before provide a code or defined explicit association in our markup. Descriptive page times are important, that is the first thing read by a screen reader when they come to a page, it is the text that shows up in the browser on the tab of the page. It is important to help define what that page is about. Also important to define document language, as content becomes more international, often we see translations of web pages, defining what that document language is, is very important, especially for screen reader users that are multilingual. They may have a screen reader that can read in multiple languages, and ensuring that it reads with the correct language, an tonation and fluctuation and language settings is important for accessibility.

25:30 - A few more thoughts on semantics. Having in html has default semantics. If you have a button, it has a default semantics of button. That is conveyed to a screen reader user, that this is a button. If you have a link, it will identify this as being a link. It is important that we use those native html elements with their default semantics to the extent that we can. When the semantics of html are not sufficient for something we are building, maybe a complex application or widget, then and only then can we use ARIA to address the accessibility gaps. ARIA is accessible rich Internet applications, it is a W3 specification for, that is W3C specification for advanced accessibility of primarily Internet applications. To take that statement a little further, we often say that the first rule of ARIA is don't use ARIA. That is actually defined in the specification itself. Right out of the ARIA spec, it says if you can use a native html element, or attribute with a semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so. That means if you can make it accessible with html, you must. That is where you start. Then you can use ARIA to go beyond that.

27:10 - Unfortunately, the reality of ARIA is that it is not making things more accessible. It is doing just the opposite, because of misuse, abuse and overuse, while the potential of ARIA is very significant, to really make things more accessible, what we are seeing instead is it's making things less accessible.

27:34 - In the evaluation work that we do here at WebAIM of websites, we generally spend more time telling our clients how to stop using ARIA, than how to start using it correctly. That is just because it's so incorrectly implemented that it is making things significantly less accessible. Be very careful, if you are going to use ARIA, promise me that you are going to do it right. Read the documentation. Read the specification. Make sure that ARIA is done correctly. Otherwise you very likely will make things less accessible, or even totally inaccessible to many users.

28:14 - What ARIA does is changes or enhances the default semantics of html elements to API values, APIs are things that channels between the browser and the assistive technology, by screen readers, so really what it does is takes the html and it scans the vocabulary of html to things that screen readers already understand. An example is ... a slider element. In html we have a slider element, no, I'm sorry, in html we do not have a slider element but we build sliders all the time. We see sliders, where you can click and slide a element to select different values. We see those in web applications quite a lot. But there is nothing in html that generates a slider.

29:11 - There is no vocabulary available in html to define what a slider is. And what the properties of the slider are, current value, minimum value, maximum value, how the user should interact with the slider using the keyboard. That is what ARIA does. The real trick or power here is that screen readers know what sliders are. They understand the language of slider. By implementing ARIA, what you can do is extend the vocabulary in html, as that is conveyed via accessibility APIs to the screen reader, you can then tell the user that this widget you have built within your application is a slider and these are the values and this is how you interact with that in a standard way. It's very powerful. Course with great power comes great responsibility and that is certainly the case with ARIA.

30:10 - A lot of what we tend to recommend with web applications, very often our primary recommendation comes down to four words, just use a button. Just use the, or select menu or a link or whatever the native html element would be for that particular thing.

30:32 - Seems relatively simplistic, and you might say, why would you not use a button to do something like a button in a Web Page? It's a good question. But we see it all the time, where developers may use it or even libraries or platforms that developers are using, they use a standard div element, a norm, interactive element, style it to look like a button and then script it to function as a button, but only to mouse interaction. That renders it inaccessible to keyboard users and screen reader users. Whereas if they used a standard html button, the accessibility would be there. It would be free, the semantics are correct, they would be relayed to the user and it's keyboard navigable.

31:20 - Moving on quickly through our couple other principles here, the principle of operable being able to interact and navigate with content, we want to make sure it works with a keyboard. Anything you can do with a mouse, you should be able to do with a keyboard. Fortunately this is easy to test. Put your mouse away. Try to navigate using only the keyboard. The significance and prevalence of keyboard accessibility issues is significantly on the rise. That is unfortunate, I think, especially with modern web applications, keyboard accessibility seems to be increasingly overlooked. That doesn't have to be that way. Most keyboard accessibility issues are easy to detect and generally easy to fix.

32:03 - As a user navigates via the keyboard they need to be able to see where they are at. You can with one little statement in your CSS turn off the default browser focus indicators. It is a halo or dash line that surrounds the element that currently has keyboard focus. As you hit the tab key it will highlight the element that currently has focus. In the case that you can now interact with that element, so make sure you don't turn those off using CSS.

32:32 - You want to make sure that the things you can interact with are clearly distinguishable. This is especially helpful for mobile, when you look at the page you should know what things you can tap on or click on to activate them. Make sure the underlying reeling and navigation order -- reading and navigation order is logical and intuitive, it follows the visual presentation flow, as you hit the tab key to navigate through a page or listen in a screen reader. You want to avoid tab index. Tab index is a way of defining an explicit navigation order. Just never, ever results in better accessibility.

33:10 - A lot of when we deal with more complex applications and widgets, especially things that are dynamically changing the interface, triggering dialogue menus, opening menus, changing the content that is visible within a page, it's important that programmatic focus, where focus is being set via scripting, follows the visual focus. If a dialogue window opens, you need to set focus to that dialogue. So a user can start to read or navigate that immediately, when the dialogue closes or goes away, set focus back to something logical within the page.

33:50 - There is a lot that you can do with ARIA to enhance operability and semantics. I'm not going to go into all of this for sake of time. There is a lot there. As I mentioned before, be very careful with ARIA just because of the potential it has to quickly destroy accessibility. We want to make content understandable. Make sure what we are presenting is accurate, clearly understood by the user. This is a area that is fairly hard to define via accessibility standards. How do you define if something makes sense? How do you measure that? It's really quite difficult. But there are some really good recommendations and guidelines in the guidelines themselves, and just common sense and good usability techniques and practices. Being careful with movement or other distracters, that animating image or background video which is becoming increasingly common or that carousel, that sliding images on a home page that automatically transition, and, animate, might be mildly annoying to you but may render the rest of the page content totally inaccessible to some users with high level of distract ability not to mention screen reader users and others. Use good organization to define sections or structure for document, headings, lists, things like that. Simplifying your content, being consistent in your presentation. You may be involved in higher education or education in general, and that idea of consistency between websites within an entity can sometimes be really jarring, and confusing to some users. Focus the user's attention on the things that are most important, using design, white space, color, use good design to help to focus the user on the things that are most important. Being careful with small text. Everybody struggles to read small text. Interestingly, this is something that is not addressed in the web content accessibility guidelines. Primarily, I think because the guidelines focus on disability accessibility. If everybody struggles reading small text you are not really discriminating, are you? And that is a important point that we do need to look beyond the guidelines to things that just make sense, especially in the area of understand ability. Avoiding long line lengths where it can be difficult to scan from the end of a long line to the beginning of the next line, you can lose track, there is overhead involved there, especially for users with low vision or some reading disability or difficulties.

36:47 - A lot of understandability comes down to balancing cognitive load and functionality. Every time you have to think, every time you are frustrated, every time you have to remember something in order to successfully do something on the web, magnify that cognitive load or effort or frustration or memory by 1,000. That might give you some indication or understanding of the type of experience that somebody with certain types of cognitive learning disabilities might have on your page. We have to balance that with functionality. We want to provide things that are meaningful and useful to your users. Often we can make things more simple, decrease the cognitive load, while also maintaining the important or critical functionality.

37:37 - Then our final principle of robust, robust deals with technology strength. To sum it up in one sentence, it is asking the question of does it work in the technologies that my users have? Does it follow standards? Is it supported by technologies and assistive technologies? That is the general idea there. Those are our four foundational principles of perceivable, operable, understandable and robust.

38:06 - If we implement and follow those four principles, what we have built is going to be accessible. These things focus on a good user experience. Of course the guidelines go in more depth than just these principles, to help inform that good experience. But if we focus on these principles, I think they are very informative to a good user experience.

38:28 - Another consideration here, I'll mention briefly, is age related processes. As we age, we tend to lose visual function, we tend to lose motor function, we tend to lose auditory function, and we lose our minds. We tend to lose cognitive function as well. All of these principles are going to support a better experience for those that likely are going to develop disability as they age. Statistically, the majority of us will experience disability at some point within our lives. That is one thing that motivates me in trying to make the web more accessible today, is that I'm probably making it more accessible to my future self. I like to think about that. That motivates me to make the web a little better.

39:22 - So, I'll take a moment and talk about potential future challenges, and things, trends that I'm seeing, especially with modern web accessibility. I mentioned the continued abuse, misuse and overuse of ARIA, and misunderstanding about how to best implement that. This is really a significant issue. ARIA is relatively new, we are seeing it everywhere and in most cases it is not improving accessibility. It is doing just the opposite. There is a lot of education that we need to do there. A lot of what we are seeing with ARIA misuse is related to the next point, and that is platforms or tools that do not integrate accessibility or don't do so properly.

40:09 - You build your website on a content management system, or you build this new widget on your website, using the standard platform or coding library. Those don't have accessibility properly built into them, then you are building on a very shaky foundation. We see that a lot. We need to work with tool vendors, tool developers, to implement accessibility better into these platforms. That will make accessibility much easier for everybody that implements those platforms.

40:47 - Similar point, there are a lot of developers tend to rely on those without really understanding even the basics of html. So when they encounter or identify potential accessibility issues, they suddenly turn to ARIA or a different platform or something else, rather than really understanding that just basic html techniques would address those accessibility issues.

41:13 - Also, considering the current legal environment, the policy environment, especially with Section 508, and the Americans with Disabilities Act, in the near future, defining technical standards for web accessibility, that technical standard being the web content accessibility guidelines, I think that is great. I think it's going to result in better accessibility. Unfortunately, I think it's leading us to focus more on strict, only compliance, without really considering the positive user experience. Accessibility becomes asking what do I need to do to become compliant, what boxes do I need to check so this accessibility thing is done. Without really understanding the user experience. Those are a few things that I've identified that we want to consider and try to address as we move forward with modern web accessibility. A quick plug for the Wave tool, it's an on-line accessibility evaluation tool. We have built it here at WebAIM. It is freely available. It can identify many or most of the things that I've talked about today, identify the very apparent accessibility issues. Of course there is much more that would require manual testing, and user experience. But Wave can often be a good starting point for identifying the apparent or obvious web accessibility issues in your website. I want to end with this quote, for people without disabilities technology makes things veen convene yent whereas for people with disabilities it makes things possible -- that is certainly the reality, in my experience, with people with disabilities, has indicated a really significant reliance on the web, and it's really convenient that I can go to the mall, shopping store, grocery store, I can get my education by going to a classroom, that it's nice to get it on-line. I love using Amazon. But I can still go to the store. You know, the web is really veen, a convenience for me, but I can still do it in other ways, for people with disabilities often the web is the primary mechanism for them to access these types of things. Keep that in mind. You have the potential to really make a significant difference in the lives of people with disabilities by making things accessible.

43:46 - With that, I'm going to stop. Yes. Please post any questions you might have into the chat window. I'll do my best to address them as they come in.

43:56 - >>

Announcer

Great, thanks, Jared. We have quite a few questions that have come up. I'm going to field them through to you, and let you answer accordingly, they are probably more on the order of the presentation, so going back a little bit through some of your earlier slides, the first question was, somebody was asking where could we get the statistics that you quoted, especially the 8.5 percent of the population affecting, being affected by computers? Do you have any particular source that you like to go for disability statistics?

44:36 - >>

JARED SMITH:

You know, it's a little bit difficult to get exact numbers of users with disabilities. That 8 and a half percent, generally, has been cited from the U.S. census, the 2000 census collected information on disability. It didn't ask specifically about disability, that would impact computer use, but in analyzing the types of disabilities that were reported, that is a pretty conservative number that you can come up with.

45:07 - There have been other studies and censuses and so forth, that generally indicate about 20 percent have a disability, and some analysis of those types, generally gets about 8 and a half percent. As far as one definitive source for that, unfortunately I don't think I can come up with one right now. But it is something that seems to be generally accepted.

Announcer

45:32 - >> Great. Thank you. A comment from me in particular, you were talking about the new standards or the new Access Board standards that have just come out, very new. They were, I was looking on-line while you were talking, that they have just been published as of January 18 which is yesterday. So have you had any chance to even have a look at what has been coming through with them? We have been waiting for this for a awful long time for them to be finalized. Looks like we finally have got it. Do you have any feedback or comments at this stage? I know it's unfair to do that to you after 24 hours after having been finalized but your comments could be interesting.

JARED SMITH:

46:17 - >> Well, I can speak to it, I was on the federal advisory committee that first made the recommendations to the Access Board on the technical standards. Of course, that advisory committee was formed in 2006. Over ten years ago, we delivered our recommendations, in 2008. It has taken until 2016, sorry, 2017 in order for those to be finalized. But they do reference WCAG 2.0 as the standard which is great. The ideas were harmony on one set of guidelines or standards for the federal government. My biggest concern at this point, the guidelines, the new standard for Section 508, technical standard, WCAG 2.0, will not be effective for one year, one year from yesterday. A lot can happen in one year, especially considering the policy environment. So I don't know what is going to happen. I've been waiting over ten years for the guidelines, and right now I'm not holding my breath for, I guess a lot can happen in one year considering the current environment. I'm very hopeful though, regardless of the guidelines, I think that awareness and implementation of accessibility is increasing, and that is what we are all about, regardless of what the technical standards require, we are going to help people make things more accessible today.

Announcer

47:56 - >> Great, thanks. In fact, what I've just done, I've posted into the chat room a link to the announcement. So anybody who does want to follow through that that, feel free to have a look at that link. It is in the Access Board website. You can just go to access-board.gov, and hunt around in there for the guidelines and standards. That will give you a little more information about that. As Jared says, important things really about this is following up with the good practices that we are all working on, and it's great that we have now got that standard behind the guidelines. Thank you for that.

48:36 - All right. The next question was to do with captioning, you mentioned that the, there are a number of tools out there to help with video and audio captioning. Do you have any particular that you like that you would point people in the direction of? I know this is not something that you would necessarily stand behind a hundred percent but perhaps point people in the direction of a captioning tool.

JARED SMITH:

49:04 - >> I don't know I can adequately answer that in just a couple minutes. There are three general approaches, one is outsourcing to generate the transcript or captions. Second is paying somebody to type it. The third is voice recognition technology.

49:23 - Studies have generally shown the three methods are about the same as far as cost or effort. As far as outsourcing, 3 play media is a popular one especially in education, as far as the service. They also do video hosting and provide captioning environment. YouTube provides good support for captioning, they do voice recognition on your media to generate the transcript and captions. With quite varied accuracy or success. Often it may take a first stab at it but you want to go back and probably spend a fair amount of time to fix the voice recognition errors that get generated. But first time media for small volumes of media that can be helpful. My primary recommendation when it comes to captioning especially for larger entities or organizations, is to centralize. Because of the cost breaks that happen as you have more volume for captioning and transcription, centralizing those efforts into one place could make a significant difference. Instead of, say at a university, if everybody on campus doing their own captioning centralizing that at the university level and having a system in place for that can save significant money and effort. And creates a centralized system that is consistent to get that, those captions and transcripts.

50:52 - Moving that even a step higher doing that at the state level or university system level, the cost and other benefits there are really significant. Regardless of the actual tools or mechanisms, centralizing is probably the most important thing you can do there.

Announcer

51:12 - >> Great. Thank you. A question about sliders, somebody was asking do sliders require JavaScript and would that be a issue or not an issue?

JARED SMITH:

51:25 - >>

Okay, yeah, generally sliders or carousels I'm assuming that is what you are referring to, content that transitions or shows different frames or slides generally down on home pages, yeah, they almost universally will require JavaScript. Is that an issue? It is not necessarily an issue that they require JavaScript. I think JavaScript is ubiquitous enough today that the question of whether you should require JavaScript isn't really an accessibility question, it is more of a general usability question.

52:06 - We found through surveys that we have conducted that individuals with disabilities tend to have JavaScript enabled at, at least the same levels as the overall population. Our most recent screen reader survey, 98.6 percent of respondents had JavaScript enabled. That is about the same as the overall population. Some people disabled JavaScript whether they have a disability or not. Whether you require it is really a broader technology or usability question.

52:39 - As far as whether the slider itself will cause issues, almost universally, yes. I could spend another hour talking about the accessibility issues of sliders or carousels. But know that they tend to pose usability and accessibility issues.

Announcer

52:59 - >> Great. Thank you. From a, building on that in terms of design, and page structure itself, you have made a comment about the use of links and too many links and being able to navigate your way through with keyboard strokes and so on.

53:20 - Would you suggest that if you are looking at design, that having more pages with less on each page is maybe a good thing versus having one page with a lot of stuff that you scroll through, you don't have to go hunting through different pages? Do you have any comments? I know that is probably a preference question, but any comments on that, one page with a lot more information or break it down into separate lots of little pages.

JARED SMITH:

53:48 - >>

That is a good question. I don't think I could make, recommend one over the other. A lot would depend on context and how it's presented. There is overhead to a lot of links on one page, there is overhead in segmenting it into other areas, that the user has to find and discover those.

54:07 - I don't know that one is necessarily best. I think the key with either of those approaches is structure. Are they presented in a usable way? Are there headings or separate pages that make it clear that the user can get to those, what they do, how they are segmented or compartmentalized. I think that's really -- of course, there would be a fundamental usability question or two of, are these many links necessary, for anybody? But if they are, either approach works as long as you really consider accessibility in structure.

Announcer

54:57 - >> All right. Then another question about, just in terms of carousels and the background, all these images that go around in the background. Can you speak to how those affect screen reader's focus, if those carousels and backgrounds are changing all the time, presumably that is what you are referring to, having making sure that your html is constantly going back to a point of focus. We mentioned it's frustrating if a screen reader is using that, suddenly the carousel changes and all of a sudden they are in a completely different space from where they thought they were.

JARED SMITH:

55:38 - >>

Right. You just defined one of the primary issues there. One is that, yeah, navigating that carousel content or reading through it, is that carousel automatically advances, one of two things can happen. One is they can be navigating content that is no longer visible on the page. You have to remember that most screen reader users have some vision. They may be using the screen reading functionality to enhance or supplement the visual experience they may have extreme low vision. Generally in that case they may be using screen magnification which is going to be a issue if things are animating or transitioning on the page without user control. They may end up in a place that they can't see, so they are hearing something that is not visible on the page. That would also impact sighted keyboard users. They are navigating through carousel content that isn't visible on the page.

56:37 - Another thing that can happen is because of the transition, as soon as the transition is away, often that content is hidden or disappears, that can cause a loss of focus. The browser, the thing to have keyboard focus or was being read is now gone so usually it will revert to the top of the page. That carousel on your page beyond just the content itself being inaccessible, can make it very difficult for the user to get beyond that carousel content. The other important stuff on the page.

57:12 - Those are issues. Others are providing context to the user so they know actually what is there, we sometimes put the controls below the carousel and how do you make an association between these dots or numbered links and to inform the user that they control the content that is previous to it, is just not a good way to do that. Just overall distraction, confusion, of course often carousel content itself is not made accessible. We have images without alternative text or ambiguous links. I could go on and on but I will stop. There are certainly issues there.

Announcer

57:58 - >> That brings to another point. You mentioned CMS and tools that people are using to better -- with the proliferation of the tools that are out there, what would be your comment about that, do you think there is awareness that is growing amongst CMS developers and certainly as more people, it becomes more easy for people to use them, so anybody can go in and develop a website now, I would imagine that has become a big issue as well. Do you have any comments about that? I know it's probably an intractable problem.

JARED SMITH:

58:45 - >>

Yeah, there are, yeah, I think awareness is increasing. But also innovation is increasing too. We are doing newer and more powerful things which is great. That is not to suggest that is a bad thing. Often we focus only on the [inaudible] without considering how accessibility can be supported in that. They can usually especially with ARIA, it is rare anymore that we will encounter something that we would tell them, that is something you can't make accessible. Most often you can.

59:22 - That wasn't the case five or six years ago when it came to, before ARIA was finalized. So yeah, so awareness is increasing. We just need to do a better job. A lot of that is being driven by the legal environment with lawsuits, threats of lawsuits, office of civil rights compliance especially in education, probably around 1,000K-12 schools that have received O.C. R compliance in the last several months so that is causing them to exert a lot of pressure back on to their content management system and website vendors, to ensure the accessibility, because often they don't have the technical ability to do it on their own.

Announcer

1:00:05 - >> Great. There are a few people have mentioned specific tools which you may or may not be familiar with. One was square space, the other one is CSS frameworks like bootstrap and workplace, are the three in particular which have come up. Are you familiar with any one of those or have comments about any of them?

JARED SMITH:

1:00:29 - >>

I know WordPress has good accessibility built into the core, bootstrap they are doing good accessibility, I'm not that familiar with square space and their accessibility. All these things can support accessibility. It's always a matter of implementation especially with something like WordPress, it provides a good accessible framework. But if what you build into that doesn't support accessibility, if your content isn't accessible, it doesn't do a whole lot of good.

1:01:02 - >> Exactly. You get back to the usability aspect of it as much as the accessibility aspect of it.

Announcer

1:01:10 - Another question was asked, do you keep tabs on ADA complaints or lawsuits which stem from website accessibility? If so, what is the most common issue that results in these complaints?

JARED SMITH:

1:01:27 - >>

Oh, I certainly try to keep tabs on things. One resource, if you want to get a good sense of what is happening in the digital accessibility space when it comes to legal aspects is LF legal.com. I'm going to double check, make sure it's right but it's Laney Feingold is a lawyer, very often focused in digital accessibility, and she keeps a very up to date website that provides a summary and overview of what is happening in that field. As far as the actual things that are causing these types of lawsuits on compliance I think it's all over the board. Generally, if you get to the point of a lawsuit, you know, generally it would Katie they are significant lack of implementation of accessibility, you simply don't care, or you thought that it didn't matter, you know. You fought against a complaint as opposed to simply addressing the accessibility. As far as like the O.C. R complaints that are happening, they tend to be filed for pretty much anything, sometimes even very minor accessibility issues which is sometimes frustrating especially for those that made a good effort for accessibility, still finding themselves facing an OCR complaint because maybe some automated tool found a some minor issue. So I don't know. It's an interesting place right now that we are in, with both the policy and legal environment. While it is resulting in better accessibility and increased awareness, often it is not the most positive approach, most meaningful way to actually implement accessibility when you are suddenly forced to or threatened to.

Announcer

1:03:33 - >> Thank you. The next one is can you explain the reasoning behind discouraging use of tabindex?

JARED SMITH:

1:03:44 - >>

Okay. Yeah. I'll try to address that quickly. So the default navigation order for elements within a Web Page is based on your underlying source code. Typically that underlying source code order will mirror the visual presentation left to right, top to bottom through the page. Sometimes with real complex layouts, or misunderstanding of how users may navigate through an interface, some people might think that they would be better off explicitly defining that order, this thing first, this thing second, this third by using tab index. The reality is that, I've never seen it implemented in a way that makes things better, at least any better than the appropriate solution which is restructuring your source code, so that it is logical and intuitive. You can maintain your visual presentation but just fix the underlying code so that navigation order is logical.

1:04:43 - Typically if you are going to use tabindex you have to use it on everything, every interactive element within the page, in order. Another primary issue with using tabindex, because the underlying source code defines navigation and reading order, if you define a tab index order that is different than the reading order, that can cause confusion especially for a screen reader user. They read through the page, hear things in one order and when they start navigating it navigates in a different order.

1:05:17 - It is a solution, but it is almost always the wrong solution. The correct solution is just fixing your source code.

Announcer

1:05:26 - >> Great. That sounds like a little bit like your comment about using ARIA, when you can just use a standard button. Clearly don't mess with it too much but rather get the underlying structure looking good.

Announcer

1:05:38 - Next question is, is there any progress on getting WCAG standards for mobile apps in the states?

JARED SMITH:

1:05:48 - >>

That is a good question. The web content accessibility guidelines are in the process of being updated now. They are currently working very hard on a WCAG 2.1. Some aspects of that update, at least as is being proposed right now, will address some of the mobile aspects.

1:06:08 - The guidelines themselves are generally relevant certainly to mobile web content. Many or most of them are relevant to data with mobile apps. The W3C has a document called mobile web best practices, that takes the WCAG guidelines and maps them to best practices for mobile development. That can be a good reference but that is based on the current accessibility guidelines. But I know that is an area that the W3C is looking to address in WCAG 2.1 and probably even more extensively in the next major version of WCAG, WCAG 3 or whatever it ends up being in the future. Probably still several years out though.

Announcer

1:06:54 - >> Great. Thank you. That sounds encouraging. Somebody just made a comment about that, that that is already applicable in Europe. This is not the forum to go into that, we don't have more knowledge about that. But that is good to know, that that is out there.

Announcer

1:07:12 - One last question that I have is, can you comment about the menu option with dropdowns, it's an ADA recommendation. What do you like or not like about menu options with dropdowns?

1:07:28 - >>

I'm going to presume you are talking about the navigation system on a website that has dropdown menus. Those certainly can be made accessible. There are some best practices for that, there are coding libraries that do that. They are called mega menus, Adobe has a platform, not a platform, that is not the right word but a coding library for those types of menus. Deque has a mega menu system that they provided. I think they are okay, if they are made accessible. Many or maybe most aren't. There is quite a bit that goes into making those types of things accessible for keyboard users, for screen reader users, in a way that is really efficient and useful. But a lot of those things, platforms can support that. So yeah. No inherent issues for sure with those types of menus.

Announcer

1:08:32 - >> Great. Thank you. In terms of WCAG going on to 2.1 and 2 point beyond that, standards, presumably the released standards are accommodating any changes and updates from the WCAG guidelines, as they go along.

1:08:56 - >>

I'm sorry. I'm not sure there was a question in there. Could you restate that? I must have missed what the question was.

Announcer

1:09:03 - >> Sorry, no, it was just a, more of a comment than a question. I'm assuming that with the new Section 508 standards, that they have made accommodation for any changes to the WCAG 2.0 which have now been adopted into Section 508, so that as WCAG 2.0 changes to WCAG 2.1 or WCAG 2 point the next, they don't have to go back and change the newly updated standards. That will be incorporated into Section 508 by default.

JARED SMITH:

1:09:39 - >>

Okay, yeah. I see. The answer really is no. The technical standards do reference 2.0, and only those guidelines. So yeah, as the guidelines themselves change, that will not automatically be reflected into the requirements for Section 508 or for ADA or any other thing that references WCAG 2.0.

1:10:04 - My hope is that the W3C will be very responsive and make continued work on WCAG, that they are going to -- the way I often summarize this, is that guidelines should guide. They should really reflerkt the current environment -- reflect the current environment of accessibility as opposed to reflecting or being responsive to the legal environment. There's some hesitation to update WCAG 2.0 for the last several years because of the fear that it might derail the policy processes, that maybe they would abandon WCAG all together in Section 508, because of the thought of what you just suggested, if we focus on WCAG 2.0 and it's outdated before we are even done defining the technical standard for 508, maybe we should look somewhere else. There has been some reluctance to update the guidelines. I think that much better approach is to have the guidelines guide, have them be updated frequently to reflect the current environment, and then I think policy environment would maybe be a little more apt to keep up as well.

1:11:14 - But right now, no WCAG 2.0 -- it is starting to show its age, it's coming on ten years old. There is more we can be looking at, we want to look at 2.1 and beyond but as far as the legal requirements, the fact that by the time Section 508 is updated next year, it will have been 19 years, since we have seen technical updates to Section 508. I certainly hope that we are not stuck on WCAG 2.0 for another 19 years.

1:11:52 - >> Exactly. At least the good news is we have got the latest section 508 so that is something we can focus on, WCAG 2.1 as it comes along will be good, it will be interesting to see but not part of where we need to worry about right now.

Announcer

1:12:08 - I think we pretty much are coming to the end. One last question which was covered already, I think, is do you have any statistics on current Web users in the disability community in terms of age, economic status, etcetera. You mentioned that before, but if you want to make one last comment about that, going back to census board or wherever you feel would be appropriate to look for those?

JARED SMITH:

1:12:32 - >>

Yeah, that is a good question. I'm not aware of like a single repository that has a lot of that. The WebAIM surveys provide insight into the type of technologies that are being used, type of disabilities, at least among respondents to the survey. I'm trying to think of the name of it. I know there's been some research studies, I'm blanking on the name of one that really, a broad swath type of survey of disability type, those types of things. When it comes to web accessibility, a few thoughts about the numbers, one is that you can't really detect if someone has a disability on the web. You can't detect if they are using assistive technology. So part of the question would be if you knew the number of users that had disabilities that were accessing your site, would you do anything different? Or should you do anything different? I think that many people would be surprised at the low number of, for instance, screen reader users, and so would that cause them to simply abandon efforts for screen reader accessibility if they knew that, or if they could detect assistive technology, would they create a separate experience for users with disabilities, and what would that mean, as a potential for discrimination there even if their intentions are noble. So a lot that goes there. So I don't tend to get hung up on the numbers or percentages, of those with disabilities. I think it's more than just categories of people with disabilities, when we talk about accessibility, and a really good positive experience for everybody.

1:14:26 - >> Great, thanks. That did answer the question for that particular audience member. That is great.

Announcer

1:14:32 - I think we have pretty much come to the end of questions, and I have to say, a big thank you to our audience. We have really got great questions that have come through today. Thank you to the audience. But more particularly, to thank you, Jared, for your presentation and for the knowledge that you clearly have about the whole subject. It is a ongoing story. There is so much that happens and so much to know about it. Your knowledge is great. WebAIM has always been a wonderful go-to source for a lot of us, myself included, to get that information. I would like to thank you again for that. And if anybody wants to get hold of Jared, you may do so via WebAIM.org or contact him, I would imagine that is your Twitter feed, Jared underscore W underscore Smith. That is one way to get hold of him or go to WebAIM in any event.

Announcer

1:15:31 - From our side, we would like to confirm that our next session which is going to be March 16, we are going to be talking with Mike Gifford and talking about Drupal's solid accessibility defaults. For those of you who have no idea about Drupal or anything like that, please join us for that particular event on March 16. We look forward to seeing you all here. And in any event, you will be getting evaluation sheets coming or not sheets but links coming to you to the evaluations. We would be grateful if you would give us feedback on that. That would be wonderful. Once again, Jared, thank you so much. This has been really helpful and we look forward to continuing relationship with WebAIM and good luck to your organization.

JARED SMITH:

1:16:19 - >>

Thank you. I really appreciate the invitation to be here, and hope that it's been helpful. Thank you.

Announcer

1:16:26 - >> Great. Thank you. For people who are looking for proof of attendance, we have that and will be sending out information to you as well. You can contact us at the ADA-accessibletech.org website if you need to get hold of us too. Thanks, everybody. We look forward to seeing you on March 16.