[Dennis]: Up now for tonight's presenter ... Joe, you're up!
Joe is a UX professional out of Seattle. He works for UX Blink ... Blink UX ... I figured I'd get that wrong. He's also the organizer or assistant organizer ...
[Joe]: Co-Organizer
[Dennis]: He's the co-organizer of the Seattle Accessibility Meetup. I actually watched a session the other day ... a fantastic, very engaging crowd that they get there. So please ... give a warm Chicago welcome, to Joe Welinske.
[Applause]
[Joe]: Well, thank you very much for having me here. I'm really happy to be here with your group and I'm from the Seattle area and one of the areas that I'm involved in is accessibility design. And as I am one of the co-organizers, we have a accessibility group like this one and we have monthly meetings and so I'm happy to be involved in that and regular basis because it's something that I do as part of my activities being a consultant with a user experience research and design firm in Seattle called blink UX. I also teach at the University of Washington and that includes class on accessible design principles and so this is an area that I'm really interested in and first got exposed to through the W3C, working as part of a working group for the Web Accessibility Initiative some seventeen years ago, and still, still involved.
Before we get started, I did want to mention that I'll make sure that my email address is posted on the meetup site. Because one of my graduate students has put together an accessible version of this presentation in a Word document format, so it's in a linear format with images and essentially the script or the things that I talked about. And so anybody that's interested in that, please send me a note and I'll be happy to send that to you and you'll have the whole presentation in that manner and you can deliver that to your colleagues as well. And by the way, I grew up here. So one of the reasons I come to Chicago on a regular basis is I have family in this area, going to "Lolla" tomorrow and checking that out, so. In fact, I worked in this building in 1988 for what was Quaker Oats. I don't know if they're still over there. But they're right across the street, so. It was a lot different, the offices weren't as comfortable and trendy and nice as this one, but it's a great place to work, looks like.
Alright, well, so the point of all this is to provide information about a case study, just one of many case studies related to accessible design that Blink UX is done with one of its clients and I already know from talking to people here that we have some people that are very experienced in this area. Hopefully I'll be we'll provide some nuggets that you aren't ... you are already familiar with. And then for people that are newer to accessibility, just kind of talk about, sort of a day in the life a typical project that we might encounter for one of our clients. And in this case, our client was VeriCite and we're involved in helping with the design, redesign of their website and their service and their software is used by universities, by educators to be able to check the originality of submitted papers, documents, text and that type of thing. In fact, at the University of Washington, it's tied into the learning system that we use there. And so, you can, students post papers and it can be instantly evaluated to find out different levels of originality associated with that. And so, being a software that's used widely in universities, that obviously, there are certain accessible design requirements associated with that. Fact, one of my colleagues at the University of Washington Tacoma is an educator who's blind. And so it essentially, the software wouldn't be available to him without having accessible design associated with it. But I did ... one of the things that I wanted to mention is a lot of the things that we talked about, or that we do at our organization, we can't talk about because it seems like everything's under NDA. And so, yay for VeriCite. And they've said, let's talk about it. We knew it was a good experience and so these are you know just kind of under the hood things that happened with this client project. And I'll just go over it in three areas; process findings and reporting. And then we can open it up for questions. I have the microphone here we can pass that around. And then I can also stick around until you know we get kicked out for anybody that wants to, you know talk about things, get in the weeds about any of the these issues, as well.
So process is the the first area and so in doing an accessible review for this product, first thing that we always have to figure out is, you know, what level compliance is appropriate. And even though this was software that was being used at the university level, contractually, there weren't set compliance standards for that. It wasn't strictly ... it wasn't a federal government contract and so the Section 508 didn't specifically apply to that. So one of the things was to identify what level compliance we're going to be reviewing the software for is part of our accessibility review. And by the way, she mentioned, the product had already been designed, and so anybody here that's a designer knows we always like to be involved with these types of things as the project moves forward. In fact that's where we get our best accessibility solutions when it's ... if you know it's a universal opportunity throughout. But here, we were coming in when the product was already mostly put together, and so we're checking to make sure it was working well. Since there wasn't a contractual level for this, we went with the W3C's double A level of recommendations through the Web Content Authoring Guidelines. And that's a standard that we've used in many projects. It aligns very closely with where Section 508 came from originally. It also aligns closely with the regulations that are established and in the European Union and other parts in the world. And so we felt that that was appropriate, and we always do document all of our ideas, our thoughts, our reasons, throughout the process. Because that helps us to be able to understand why we did what we did, and if questions come up later, to understand why we did things at a certain level of compliance. Now this client, it had not gone through a formal accessibility review before, and there's certainly a lot of different tools, commercial, non-commercial, that can be used in order to be able to do evaluations. But one of the things that we wanted to be able to do was, have tools that the client would be able to work with later on after the project. And so, one of the things that we used is a tool that anyone can use, which is publicly available from WebAIM.org which is Wave. Which provides ... sort of a top level overview of software and matches that up to the guidelines established by the World Wide Web Consortium's Web Accessibility Initiative. And it's fairly easy to work with.
We work with other tools as well that are a little bit more powerful than that, but I bring this one up because a lot of people that are just getting involved in this, I find it's a good starting point, because anybody can get Wave for free and you can check out any webpage that's on the public facing web and be able to get an idea of what it means to to see what complies and what doesn't comply with different levels of the W3C. And so, on a typical Wave screen, it'll provide a representation of a particular webpage and then that web page will also have icons associated with different parts to it, and represent issues that it's found related to those W3C Web Accessibility Guidelines. And each of the individual icons is then something that you can use to delve deeper to find out particular problem. Now, in doing this accessibility review, one of the things that I that I always do is keyboard only testing and to me, that's extremely important and fortunately, like I'm old enough where actually I did work with software where you had to use a computer. I realize that a large portion of the audience has no idea what that's really about. But I ... keyboard access is more than just the keyboard, because keyboard access also is closely tied to the ability for other assistive devices to be able to understand what's going on with the software and to be able to communicate that to users through different assistive devices, and that may be something that's very different from a physical keyboard and so, it does take a little bit of work to to get used to that, just navigating through a system using only navigation keys, using control key combinations, which isn't something that we do very often, and completely eliminating your use of a pointing device. And one of the things that you find as you do keyboard only access and you identify issues where you're not able to control all the features of the software is that very often it comes down to some aspect of the coding, where it wasn't put together in well-formed HTML, CSS and so on.
So organizations that I have very tight libraries that have been vetted, I tend to not have a lot of keyboard control issues, but I'll show a couple ... as we go through where it wasn't just a coding issue. By the way, I associated with the slides and in the support document, the accessible support document I have, I include information about the associated guideline, as you see, as is numbered in the document and in the slides. In this case 2.1.1 Keyboard Level A, which is a foundation aspect of the W3C recommendations, so we felt that everything ... we demanded that everything had to be at the double A level, which means it's certainly to pass the A levels. Also screenreader testing and ... I have a colleague who uses a screen reader on a regular basis with his laptop who's blind and there's no way that I'm able to use the screen reader to the robust level that my friend Taylor can. But I have taken the time to learn how to use a screen reader and so I do reviews of software only using the screen reader. And so being a sighted person, I'll put something over the screen and attempt to work with the software only working with the screen reader. And that's a skill that, I think people it just start using with a screen reader, whether it's NVDA or JAWS or Voiceover with the iPhone, it can seem a little challenging. But it pays off so much to be able to get that extra bit of understanding and clarity about where there may be gaps in the system. And by the way, I want to mention that there's no substitute for also having as part of your team, people with various challenges that are then going to vet the findings, and do testing in a real-world capacity. And that's something that Blink does do. So usability testing is a big part of Blink's work and fortunately Blink also happens to run a recruiting agency. And so we have the opportunity to find people that can do that kind of testing for us. Now, to make sure that I'm able to work through a review in an organized manner for the keyboard-only testing and working with the screen reader, I'll put together a script for myself, that has all of the key use case scenarios that we want to be able to test for. And so, then, that's what I'll do. I'll go through that using the screen reader and keyboard access and try to identify various issues with the software. If you have existing documentation for your product or service, that helps a lot, because you can just work with that. And that will come into the process, in the reporting, a little bit later.
So now, I'm going to jump into the findings and I won't be able to get into all of them, but some of the things that that we often find in accessibility reviews and one of those hidden messages and controls and this is where a particular piece of the software user interface is simply not giving information to the operating system in a way that the keyboard annal or the screen reader is able to process that information. And in this particular example, it wasn't a coding issue on the team that was at VeriCite. What it was in fact was that there was a certain software widget that was part of a third-party library that was part of the code base and that particular library item had not been built with accessible controls associated with it. So this presented an interesting challenge, which is that the developers at VeriCite didn't have the code for that particular widget and so then it's either find a different library item or find source code so that you can make adjustments but it is the case that that good software development tools also recognized that having those tools be fully accessible is really important. But this is an example where it wasn't just a simple coding issue. Something that was a coding issue that that can be dealt with are where you have hover text for example, that is usable by someone who can see and then mouse over particular piece of the user interface. And in one of the examples, the hover text would provide helpful information but that helpful information didn't exist unless ... except through that hover text. And so then you're presented with situation where you have to do some thinking about how you want to have that information, you know, be delivered to the user through the user interface.
There's different processes, different philosophies about how to approach that. Some things that come up are directly related to code issues. For example, one of the findings was related to labels that were on the user interface, where it wasn't using the appropriate code to be able to make that particular form item uniquely identifiable through keyboard access and the screen reader. And there are a lot of examples of things like that and fortunately those are ones where once you identify one instance of it and you make the adjustment in the code, it can propagate throughout the software system. So sometimes when you'll do an accessibility report, you may get this extremely long list of issues of essentially of bugs, but you may find that one of those issues crops up 85 times. And it's just the same issue. And if you're able to do a global replace of that, you can often just check that one off and be able to move forward. In that particular item again, I'm associating in this document the W3C recommendation. So 1.3.1 Info and Relationships, again another foundation level A, the information is either in text form or can be programmatically determined. There's a couple of researchers at the University of Washington, Jacob Wobbrock and Richard Ladder, who just recently retired. But, their research includes just an amazing number of assistive devices that have been developed over years to help people with very specific challenges. And those assistive devices are tied to ... those assistive devices ... I'll share the one common issue that they're relying on a software user interface to be programmatically visible, to how that device works. Now, here's the next issue that I want to talk about, is one that was a big problem for design and for development and is just a big issue generally, which is when you're using color as a way to impart information in the software user interface and in this case, when an instructor would process a paper in VeriCite, it would highlight individual sentences in that paper and attach a color code to those sentences based on the likely percentage that that information was not original. And so it was somewhat like a heat map scale where orange was highly likely that something wasn't original to a lighter orange to a yellow. And the thing was, this was a very popular method of presenting that information to people that could see it. Color in that situation is able to provide a grasp of your overall feeling about that, and this is where we get into, what I think are the interesting design challenges for us is not just dealing with the the technical issues of the accessible design but rethinking the overall design so that it can be useful to anyone that's using it. And actually, I think I would ... I'll just let me just jump, open things up here or just to ask, what could be an alternate way to do something like this that would provide that same value to anyone that was that wanted to get that kind of information? Any thoughts? Yes ...
[Attendee]: [Indecipherable]
[Joe]: Oh, I'm sorry, should I do the microphone for that? Ok, go ahead ...
[Attendee]: Change the size of the font.
[Joe]: Change the size of the font, and then how is the size of the font then rendered to ... to people that aren't able to see the size of the font.
[Attendee]: They'd have to have after maybe every sentence a percentage or a certain interval.
[Joe]: A certain percentage ... alright, so ... and what was your name?
[Attendee]: Anthony.
[Joe]: So what Anthony is doing, he's kind of ... backing up a step on that which is what is it about the information that we had before we applied the color, and can we then impart that in an alternative way. And so, it's possible then that the UI could in text and audibly provide percentages for those different values throughout. Now this is something ... this is the kind of thing where there's not an easy solution to it but we kind of embrace that, which is it ... yes go for it ...
[Attendee]: I've seen some sites where the user has control over the color and the font size and is that a possible solution, the ability to change color and change font size?
[Joe]: And what would make it something that would provide you with the mental model of the overall feeling about the originality of the information?
[Attendee]: So, I gather that for each block of text, that for some people, they do not see the text probably because of font size or the color contrast, and so that's why I had suggested that perhaps if you allowed them to control that themselves, then it would become a ... experience for the user, so some people could see the current ... yellow ...
[Joe]: Yeah
[Attendee]: That's a good idea, so the legend is actually interactive, you know, you can click on it, it's a legend that's interactive. Therefore, keep me honest Allen if I hear you correctly, the idea is, you can customize each one of those things, however it would make sense to you, or even ... you can click on it and maybe you can focus on it, and then it just brings things up to the other gentleman's suggestion, the font becomes larger, maybe it identifies it, maybe for a screen reader, it actually reads all the high matches. So it's how you sort, how you create maybe a slightly different hierarchy of what you are looking at and prioritize it based on whatever makes the most sense to you.
[Joe]: Yep. Any other thoughts about that? Looks like we had another comment over there ...
[Attendee]: [Indecipherable]
[Joe]: Yeah, that's good. So there's ... oh go ahead, let's take, did you want to ...
[Attendee]: [Indecipherable]
[Joe]: This is ... this will show, other than a screen capture, normally you'll see a page of text from a student or a passage of text.
[Attendee]: So, um, what if you had a sort of think of it like a tag, but it would be something that could be ... high match and high match. [Indecipherable]
[Joe]: Yeah. These are the kind of discussions that come up once we've done this initial accessibility review and then I you know ideally we start you know rethinking of better ways to do this, but in this particular case, this then becomes a somewhat fundamentally difficult part of the software interface to make an adjustment to. So it requires a commitment on everyone to recognize that things may have to go back a ways to, in the process, to be able to move forward with a better design. Well let's ... let me go over some other things. Now I ... whenever you're talking about color, there's also the issue of color contrast. And I have issues discriminating between certain color combinations myself, which you know people that don't have that issue, don't understand it my wife doesn't understand when I say, I do not know what actually what shade that is. But fortunately, there's been decades of research related to different types of color issues that are related to sight and much of it, well all of it has really been converted into math. So there are underlying tables that identify ratios between foreground and background colors that have been matched up to common issues that people have in identifying one color from another. And so, a lot of tools are available to be able to identify the problems and then also make the adjustments. And so, in this case, it's going back to the Wave tool that I mentioned. There was a failure of part of the software ribbon in terms of the background color, which was a charcoal gray and the foreground color which was an off-white, and this is one of those areas where sometimes I'll encounter pushback from people that were involved with the design of the palette. But once people understand that you can just make small adjustments to those color combinations to make them work for people, that kind of makes everybody happy again. In fact, in this case, for this background in charcoal and the foreground in an off-white which did not pass the contrast ratios, just using a tool like, for example, colorsafe.co, you can iterate and experiment with different color combinations. And you can come up with one that has a ratio that does meet standards. But to most of us you would never notice the difference between that background and foreground color. Just about every project, color contrast gets flagged in some way or another. But we also know that it's a fairly easily solvable problem.
Another item that we find in a lot of projects is the use of heading style tags, either not using them or using them incorrectly. For people using screen readers, properly used heading tags h1 h2 and so on, is one of the ways that you can impart meaning that can be interpreted by various assistive devices. so that the heading one versus the heading two and the heading three, that's important to people that are relying on understanding that structure. Where we run into a problem is in sites where heading tags aren't used at all and so the screen reader isn't able to use that device to be able to do hierarchy. But another case, and the one that we had in this product is where those heading tags are used for presentation purposes, for sighted users, which is, oh the h2 tag by default has the font that we like and it's bold and it's pretty close to the size that we want to use in most browsers. Unfortunately, that then can be a situation where you're applying heading tags to parts of the text that aren't part of that semantic hierarchy. And so, that was the case here. So, there was a, for example, just a data piece in the case that I'm reading East Side King County Washington, that had an h5 heading five tag associated with it. So we never want to do that. The more appropriate method is to use our cascading style sheets, develop a class specifically for data types, totally disconnected from the headings. Yes, sure ...
[Attendee]: [Indecipherable]
[Joe]: It's an interesting issue where ... first of all you like you have issues just about, just the development and management of the software, but then there's also an issue about whether or not the operating system itself is already providing some ways for people to adjust that. I guess I don't have a great answer to your question, in that I think on any given project, you just have to think through it to make sure you know it's matching the needs of the project.
Let's see, so everything I've looked at so far has been an A or a double A issue. But, there is also triple A issues. And some sites, you know, attempt to be able to provide that, which in the web accessibility initiative, is sort of our best our best attempt at being able to make everything as accessible as possible to people with a wide variety of challenges. But now, Triple A is beyond what we said is our own compliance level and triple A also ends up being outside of most Section 508 and European Union guidelines. But, still, there are there are issues there and the one I had just mentioned right here is when you're using abbreviations in the software interface. For sighted people, the abbreviations can be instantly determined. In one case, for example, abbreviating the word points with PTS. Now, when and in the example I'm talking about here, there's a field that has the label grade and then that field has two data items that can be there, but in this case, the data items are null. So there isn't data to put there and so it uses two dashes for each of the missing data points, followed by that abbreviation for points. And in the screenreader that comes off as ... oops, I'm sorry about that ... oh good I didn't break anything. What that comes out as is gray dash dash slash dash dash pts. And so, somebody using a screen reader is going to get that as their experience. Is that going to keep my friend who uses a screen reader from understanding that? No, but it's annoying to me, so I wouldn't you know be annoying to anybody else. And so, I try to look at acronyms and abbreviations and identify whether something is an acronym, that's part of a typical business case that someone would be familiar with, or if I'm just doing something to save room and user interface, in which case, I may want to re-examine that.
[Dennis]: One thing is the about abbreviations. Anyone, if you have frequently asked questions, be careful of using FAQs. You're basically communicating an F-bomb. Of you don't believe me, listen to a screen reader.
[Laughter]
[Joe]: Well I ... so that brings me through some of the typical findings that were a part of this case study that I thought you might be interested in. They're a lot more than this, but I want to stay within our time amount and just talk about the reporting process. And, first of all, just to mention that the time tracking for this project for my work in doing an accessible review of this existing project had me spending close to 50% of the time running the test with the keyboard and with the screen reader to work through the software user interface and an additional 10% ahead of time to analyze the system to see if the tools that I'm using are going to be appropriate for that. And so, that makes up a large amount of time, which, in my examination of how I've spent time on accessible reviews versus reviewing user interface designs for other aspects, it takes about 20 to 30 percent more time to be able to work with the screen reader and the keyboard access, in addition to the normal testing and vetting we might do for quality assurance of our products. So, I just wanted to throw that metric out just as an example. But then, and also in terms of the reporting, there's the issue of the handoff to the client, and despite the fact that accessible design has been a thing for a long time now, I would still say that the large majority of digital products and services are paying a great attention to this particular area. And so, when people decide to get involved with it, often the people in charge of our client's work may have differing levels of experience in terms of accessible design issues. And so, I always have to consider that when I'm talking about the results. So, if you're talking about whether a button should have been blue or orange, that's pretty straightforward to most people in design, but when you maybe get into a discussion of any of the things that we've just looked at, you know, takes some understanding of what accessible design is all about. So that's an issue and but then maybe even more difficult is being able to present the findings to people that haven't been involved in the accessibility review, so that they can make the adjustments. So maybe in-house designers that were handing off a report to and remember, keyboard-only access I think is important, screenreader understanding is important. So what I do is, I use a product like Camtasia to record every session that I do with the keyboard and with the screen reader. An external camera and I'm able to capture each of my sessions as I do the review. And so, that's available so that anybody can look at those go through those videos and be able to identify what the issue was, where it occurred and match that up to the reports, which I mentioned earlier, so those same sample use case scenario documents that I use for are working through the software, then become the place where I embed the information about the various findings. And I also try to do that in a way that can be searched programmatically, so all of the findings are in this Word document are given their own style. So findings have their own style, you can search on those, to be able to identify those separate from all the other information in the document. They also have a check mark, which can be programmatically determined and also have a color associated to that particular item. And then additional notes, I also use Word styles, give notes a different style, precede each note with the Word note and so that information can also be programmatically determined. But then, this becomes the document that goes to the client, along with the repository of the videos. And of course those videos can be closed captioned with a service like rev.com.
So a couple of final notes, I mentioned Wave reports and there are limitations to using that tool. But it's really meant as a way to evangelize what is possible in terms of identifying issues with software. But Wave only works with web content that is on a public facing server. So if it's a subscription-based or it's behind a security firewall, Wave can't access that. This was a subscription-based product, but there wasn't a security issue about the privacy of the software service. And so what we were able to do was, within the subscription firewall, save copies of all the web-based pages, along with their HTML CSS and JavaScript components etc., and then post that on to a public-facing server and then run the web report, the Wave reports off of that content. But for people where there is a privacy issue related to the content, then a tool like this isn't something that you'd be able to use.
Last thing I want to mention is, I just to take aways, which I've mentioned a couple of times, that I think it's important to gain keyboard only and screen reader skills, think about using scripts and video recordings to supplement the work that you do in the reporting, and one of the things I didn't mention separately is just building a library of solutions. So we try to keep building that up and a lot of things crop up repeatedly on projects, so it's good to remember what happened. We have a code sample, so that you can make things easier going forward. And, yeah and just keep trying to do better as we move forward. And the last thing I want to mention, just getting back to testing, using participants with various physical challenges, the employment rate of people with various challenges in a lot of cases is extremely low compared to the general population. And so, what you'll find is that, you know, gathering together a team of people that you can rely on to be able to be good testers for your accessible designs is also something that just provides a valuable employment opportunity for people. And so, we've had really good success building relationships with people that we can rely on to help us with different parts of the final testing.
Alright, so, that kind of wraps things up. Again I want to thank VeriCite for allowing me to talk freely about this stuff. I work on this stuff all the time and so feel free to connect up with me, you know, afterward about that. I can send you that document version that I have available and so and ...
[blip blip blip sound]
[Joe]: ... there I am right at the end of it. And the other last thing I wanted to mention is that I'm also the program manager for Blinks Convey UX Conference. So it's a our local Seattle UX conference and I'm taking proposals for sessions for 2018. So if you're interested in making a visit to Seattle, definitely get in touch. And I definitely love to look at what you have in mind so ...
[Applause]
[Dennis]: Question for Joe?
[Joe]: Or generally?
[Attendee]: Do you find the screen readers to be consistent across the different ones? Do you have to design specifically for the certain brand or the certain predominant player in that space?
[Joe]: It's a good question. I think the question it partly is, you know, what's going to be appropriate for your particular project. So in this project, I felt that using the NVDA freeware that's available was acceptable. But I have a colleague of our accessible meetup in Seattle, working for Wells Fargo, where her team regularly uses every screen reader, they check, do cross browser compatibility, they have a whole list of various tools and issues that they test for. And so I guess the short answer is, it depends. By not trying to trivialize it, it's just that in some cases I think like in this situation, that using something like NVDA can identify a good amount of the potential issues.
[Attendee]: Thank you.
[Dennis]: I need my workout.
[Attendee]: So you were mentioning you doing more, sort of heuristics. So, what is the determining ... [indecipherable] ... when do you determine, you know what, I need to have three or four people looking at this, through different devices, do you start saying "Hey ... we need to start looking at this on mobile, and then when you sort of consolidate those ideas and say Hey ... this is where we might need an expert walkthrough, where we bring in somebody who is either visually, cognitive or perhaps audio on challenges. Just give me the sense of, what are those tipping points? Because right now, you're ... what I assume is that pie chart you shared was basically your effort. But, you know, UX professionals usually want ... [Indecipherable]. You know, just to get a sense of the global issues and then to zero in on those expert reviews.
[Joe]: So, for example, at Blink, everything there is done collaboratively. And there are several people that are involved in the process. But it really does come down to, you know, every project having ... talking about exactly the things that you talked about, which then come up with the things such as the compliance level which then also loops in the client. For example, in this case, one of the questions we had was to identify what contractually is an issue. And that can vary from project to project. And ... but one of the more practical issues that is a challenge for me as so many that ... that is really interested and cares about this issue is that, for every client like VeriCite that has chosen to build this into the design and research of their product, that's only a fraction of the work that's being done out there. And so, a lot of the work that we've been doing over the last few years is just trying to be able to have a conversation with clients that haven't been doing accessible design, to make them understand that there are really good reasons to add in the 20 or 30% realistic costs over what they're doing already for designing research to be able to effectively provide these techniques.
[Attendee]: I have a two part question. The first question is the reason that you're saying about, you wanted to ... you only test on the front-facing website ... [indecipherable] ... where ... [indecipherable] ... And, the second part of the question is, [indecipherable] ...
[Joe]: So on that first part, in terms of mobile, one of the things that we found that just a strong hardware issue is just the level to which people who are blind have embraced the iPhone specifically over other devices, specifically because of Voiceover. In those cases, for mobile first, mobile only, then the iPhone in fact becomes a device that's the most important device to be able to test for. And so, in that case, it's a matter of being able to have facilities available and to be able to do the interviewing and capturing things with video as part of the testing process, and then, naturally, I'm not sure that the design of the ... I don't want to say that it's harder to design for mobile, because in many ways, designing mobile first simplifies things across the board. And so, I think that's one of the things that you notice is just you're coming from a simpler base point, where then you have less problems as you scale. And then your second part of your question was related to the relationship between deaf and blinder, or?
[Attendee]: [Indecipherable]
0:58:07.500,0:58:15.500 [Joe]: So, you're certainly being able to make sure that there are text equivalents for anything that's audio related, which is a big ... that might be very soon or maybe right now is ... could be the biggest non-compliance issue, is just not having a suitable closed caption alternative. But, I also really believe in having available for videos a transcript version and that's something that some people don't like, it's like an extra link and it's an extra document and it's extra part of the process. But I think a transcript can be really useful. But that closed captions is the biggest part and a lot of organizations will just rely on, let's say, YouTube to be able to do the captions. But anybody that really cares about that notices that the fidelity tends to be very low and it doesn't like meet my professional quality and so you know we would use a professional caption for that. Yes, go ahead ...
[Attendee]: ... was that, I read an article Dennis, I think it's one of the articles you shared. And it talked about YouTube, the auto caption, it's only three or four percent off. Then it literally, it is not comprehendible. So, somebody who's deaf, they will not be able to understand whats there. So, keep in mind of that. Don't worry, three or four percent. Well guess what ... that three or four percent means they can't understand what's being described. Now I don't have any idea why companies don't use transcripts, you know, because, I have a cognitive disability, I'm dyslexic, and I love transcripts, because that's my notes. So I don't understand why companies shy away from it, an extra link? You know, I don't understand ... sorry ...
[Joe]: No, no ...
[Attendee]: Because to me, it's such minimal amount of extra work to just help so many people.
[Joe]: Yeah, like, I'm old, so I like ... I do old things, like start with a script for a lot of videos that I'm involved in, and so, the script becomes a transcript, becomes your closed captions, and in your ahead of the game. But that's not the way that a lot of that content is developed today. Yes ...
[Attendee]: You had mentioned that you had to adjust the report of your finding for the understanding of your client. I'm wondering is there a website or some sort of resource, a Nielsen Norman, the reports specifically on the various communities that need accessibility? Can you point us to a great resource for that?
[Joe]: I don't have a specific resource, but are you meaning like examples of ways to communicate?
[Attendee]: So, like, I'm arguing against using color used to differentiate selections, select UI. And when I'm advocating for that, the people who are all about the minimal viable product are like, we'll worry about that later. I just need the means to say, "hey look, this is ... color acuity represents this segment of the population, this many people are not going to see this. To kind of hold their feet to the fire.
[Joe]: Yeah, I don't have something like that, but you're getting at the core that which is like actually and run some projects like maybe someone who's involved in initiating accessibility in your organization is interested in how is this helping with conversion, how is this helping with supporting us generally, how's this helping us legally, but like on this VeriCite project, when I got into the report discussion with the client, the person involved there was the head of the dev team, who was totally on board with this entire project in its entirety. But what that person wanted from me was a bug list. What's the issues, how do I find them, because we want to fix start fixing them right away. And so, it was a completely different kind of conversation. That person wasn't necessarily interested in those issues about conversion and things, but just like how do I fix that, and so that was what I was alluding to is, just may need a different approach to talk about that.
How are we doing on time, are we doing alright?
[Dennis]: Two last questions.
[Attendee]: Well, actually ... about the captions, with the videos, I'm also like you. And so I went around before there were voices on the computer and so I find that the transcripts are absolutely fantastic. It allows me with a screen reader to skim through, get what I want, and get and be done with it, but also ... I use braille a lot ... [indecipherable]
[Dennis]: And the final question ...
[Attendee]: You mentioned early on that the VeriCite university had a blind educator, that really provided context to this. If you did not have that situation, would you have had any trouble in expenditures to pull out accessibility for faculty staff versus student facing interfaces? That's something I run into a lot, if it's student facing, I can sell it. If it's faculty staff, I can't, I work in higher ed too.
[Joe]: Yeah, I think that you bring up an interesting point. In a couple things related to that is that I actually like, although that my colleague, I actually never discussed VeriCite with that colleague, but I'm always trying to meet as many people as I can in every community that there is and just be able to appreciate everybody's particular challenges and I happen to know, you know, recognize from other things that that instructor has those kind of challenges. But in this particular case, on this is the kind of issue where most ... the attention was really just about the experience of the user in this case, which predominantly was the instructor, but also was the student and so in a way to the nature of this software kind of meant that the instructor was represented, but I felt like just from teaching generally, I recognize what you're saying about student body generally having kind of the priority in terms of how we work things out.
[Dennis]: I lied ... one last question ...
[Attendee]: So, it's kind of like a two part question.
[Laughter]
[Joe]: Uh oh ...
[Attendee]: It's automation and doing automated testing. What's the best way to approach automated testing? We already have developers who ... [indecipherable] ... but how do we roll accessibility into those tests? That's part one. Part two is, at what point does automation ... [indecipherable].
[Joe]: So, first of all, I'm probably not to person to answer that you know in the best possible way, except that, we've asked actively discussed what automated testing means within Blink's consulting organization. Most of what we do is more qualitative, because that's just the nature of our practice. But, it's recognized in the research design and dev for products projects that are worked on generally that automated testing is here and it's a big deal. And in fact, there's automated testing specifically for accessibility issues, but we haven't gotten there, where I have any you know, anything I can tell you a good answer for that and possibly we have people here that might but I don't.
[Dennis]: One thing I will say is, right now, I'm captioning Marcy Sutton's presentation, tow or three times ago, on automated testing on our YouTube channel. And with that, thank you very much everyone for sticking around. Hope to see you next time.
[Applause]
[Dennis]: Thanks to our presenter Joe Welinske.
Thanks to our co-host, the and UX Chicago Meetup.
Visit them at meetup dot com forward slash and UXCHI
Thanks to our venue host, Capital One. What's in your wallet?
Captions were provided by Alternative Communication Services. Visit them at ACSCaptions dot com
Captions were sponsored by McDonald's. We're loving it!
Thanks to our sponsor, Sticker Giant, for all the meetup stickers. Visit them at Sticker Giant dot com.
Thanks to Rosenfeld Media for their discount for our members. Get 20% off really great books using code a11ychi.
Join the accessibility slack. To subscribe, go to web dash a11y dot herukuapp dot com. After subscribing, to join in the discussion, visit web dash a11y dot slack dot com
This recording was produced by the Chicago Digital Accessibility & Inclusive Design Meetup. Visit us online at meetup dot com forward slash a11ychi Visit us on Twitter at twitter dot come forward slash a11ychi Visit us on Facebook at facebook dot com forward slash groups forward slash a11ychi Visit our YouTube channel at goo dot gl forward slash GfcU9A