Preview: One thing that’s been missing is that translation of those requirements that are out there, from the standards into an actual set of standards for the project itself. You know, these are design standards. These are pattern libraries for using coding. You can have all this set up prior to beginning of development. And if they’re already in place, then that gives the designers something to pull from and they don’t feel like you’re going in there and making changes so they’re not aligned mid-design because that’s the most costly type of fix is to try to and fix something once it’s already been started working on it. If we can get those standards and requirements into place before that work begins, then we won’t have to redo the work later down the road.
[Music]
Lea Alcantara: From Bright Umbrella, this is CTRL+CLICK CAST! We inspect the web for you! Today we have Jason Nakai to chat about practical implications of implementing accessibility on websites and software. I’m your host, Lea Alcantara, and I’m joined by my fab co-host:
Emily Lewis: Emily Lewis!
Lea Alcantara: Today’s episode is sponsored by the Performance Matters Conference. The first annual #PerfMatters: Web Performance Conference is taking place in Redwood City, California, halfway between San Francisco and Silicon Valley. This year’s conference is on March 27th and 28th with a full-day workshop on March 26th, helping those newer to the web performance field get up to speed, pun intended, on everything they need to know to get the most out of the 2-day conference, featuring diverse experts in the field of web performance with three talks on accessibility and performance. Tickets are on sale now. A 50% workshop diversity discount is available to ensure the conference isn’t out of reach. Register now at perfmattersconf.com. Hope to see you there.
This episode is also brought to you by our friends at Focus Lab. On September 28, 2017, a hurricane of unprecedented strength left the people of Puerto Rico trapped without power, water, communications and access to food. Five months later, conditions are slowly improving, but thousands are still living in darkness, unsure what the future holds. Help us turn the tide, Focus Lab is selling a shirt designed to honor the strength, love and resilience of the Puerto Rican people. All proceeds from this campaign will be donated to UNIDOS, a program by the Hispanic Federation and Bright Umbrella is matching up to $500 of shirt sales. Buy a shirt, help Puerto Rico. Learn more at focuslabllc.com/pr.
[Music ends]
Emily Lewis: Today we are returning to the topic of web accessibility. This time focusing less on the tech and the requirements for different guidelines and more on the practical challenges of an accessibility project with things like project management, client expectations, and then even planning for actual development and testing. Joining us today is Jason Nakai, a software engineer who loves producing accessible and intuitive products that people enjoy using. Currently, he is the information architect and usability engineer on a large scale healthcare project and he recently worked with Bright Umbrella on WCAG accessibility for a college website. Welcome to the show, Jason!
Jason Nakai: Thank you all for having me.
Lea Alcantara: Absolutely. So Jason, can you tell our listeners a bit more about yourself?
Jason Nakai: Sure. I am a tech generalist from the Dark Ages.
Emily Lewis: [Laughs]
Jason Nakai: I live in Albuquerque, New Mexico with my beautiful and brilliant girlfriend and our three cats.
Emily Lewis: I think our listeners should know that his beautiful and brilliant girlfriend is me. [Laughs]
Jason Nakai: [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: Yes, yes, it is. Full disclosure.
Emily Lewis: [Laughs]
Jason Nakai: But aside from spending time with my girlfriend and cats and work, I run a lot, and I usually have one or two projects at the moment going on at any given time, so that’s basically what I do.
Emily Lewis: And you actually have your first, is it your first ultra-marathon or your second ultra-marathon coming up this weekend?
Jason Nakai: Yeah, that’s why I’m currently taking up my one or two projects at the moment is preparing for a 55K race this Saturday.
Emily Lewis: Oh.
Jason Nakai: Which I’m really, really looking forward to.
Emily Lewis: [Laughs]
Jason Nakai: I’ve been training for about six months to run that, and yeah, it’s been a long six months. [Laughs]
Emily Lewis: In terms of your tech generalist from the Dark Ages, how did you actually get started working on the web and in tech?
Jason Nakai: Well, yeah, that’s a really convoluted story.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: But a short version, I didn’t start working in the web until about 1998. I actually was a parachute rigger in the US Army. I was working at the 82nd Airborne Division for a few years, and I was getting ready to get out and realized that I couldn’t really do too much with parachute rigging on the outside.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: So I extended my enlistment and changed my job deal to multimedia illustration, and through that program, they sent me to art school. I learned how to draw, I learned how to paint, and after that, I went to graphic design schools. I learned how to apply all of those skills I learned previously to digital area. During that time, the Pen Tool became my best friend, which I still today count as one of my most valuable skills [laughs] is to use the Pen Tool.
Emily Lewis: [Laughs]
Jason Nakai: And after that, I went to sort of a multimedia course where I was able to package all of these things I had learned into an application at the end or a presentation. When I was working for the military, primarily I worked on information kiosks. Also, I created a bunch of information displays. So those are basically what I mainly did, and plus I did a lot of Photoshop retouching, so that’s sort of how I got into the digital part of things. Once I got out of the military, I started working for a couple of startups. During this time, I was doing mostly graphic design, so I took on the job, I went home, I bought book, PHP and MySQL in 24 Hours. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: And I went through the book for a whole weekend and that was my first introduction to the web.
Emily Lewis: Yeah, the old school days when we just taught ourselves everything. [Laughs]
Lea Alcantara: And we still used books. [Laughs]
Jason Nakai: You’re exactly right. [Laughs]
Emily Lewis: [Laughs]
Jason Nakai: Well, that was a big thing back then, and I think that’s still a problem today, it’s hard to get the training that you need to deal with today’s problems and issues through traditional forms of education. Schools don’t move as fast as the needs of technology moves. So luckily, I feel lucky to have grown up in that era because that’s basically formed the way I approach my job today, which is constant learning; you never stop learning.
Emily Lewis: [Agrees]
Jason Nakai: And luckily the way I got into it sort of taught me that.
Emily Lewis: So let’s go ahead and get into today’s episode. So we already talked about the basics of web accessibility in an earlier episode with Gregory Tarnoff, and we’ll make sure to link to that in our show notes for our listeners. If you haven’t tuned into that one, definitely I think it’s worth listening to that one first before this one.
Lea Alcantara: [Agrees]
Emily Lewis: So that’s kind of about the basics of web accessibility. Jason, you’re working on right now some software accessibility. How does that differ from web?
Jason Nakai: Well, that’s actually a great question and that’s a question that I seem to run into on a weekly basis on this current project that I’m working on. The whole new requirement of WCAG 2.0 Standards for the government just actually just recently came into effect this January so it’s still very new for this type of project, but not to say that accessibility standards haven’t been around. The 508 Standards have definitely been out for some time now, but what this new requirement to also adhere to the WCAG 2.0 Standards, it just sort of given it a little bit more weight to the accessibility issues.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Jason Nakai: And so that has been again still new, but definitely a positive I can see.
Emily Lewis: [Agrees]
Jason Nakai: So getting back to that question, so there was a lot of debate when WCAG 2.0 first came out. It was being promoted as a standard that could also cover non-web-based software applications.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Jason Nakai: And there were a lot of people who were involved in that standard that they raised their hands and said, “No, this isn’t a one-to-one comparison. Some of these things don’t translate just across the board from a web page to a standalone application. There are some things that either don’t pertain to a standalone application or if they do, it does so in a different way than what it was stated in the WCAG 2.0 Standard.” Again, I’m using this acronym, WCAG. For your listeners, it stands for the Web Content Accessibility Guidelines, and it’s a standard put out by a subgroup of the W3C.
Emily Lewis: Can you give me a simple example of that? So maybe something where WCAG says you have to do something, but that doesn’t apply in a software environment.
Jason Nakai: Sure. There are quite a few things. Let me give you a little bit more background on this really quick. So once the people that were involved with the standard and they were raising issues they had with applying it to software, that prompted the formation of a task force, WCAG task force, and this was basically tasked with creating what is called working group notes. It’s sort of a revision to the WCAG Standard, an edition basically.
Emily Lewis: Oh, like an amendment or something.
Timestamp: 00:09:59
Jason Nakai: Yes, an amendment, thank you, and basically it’s applied to non-web information and communication technologies and this year, the title is the WCAG 2.0 to Non-Web Information and Communications Technologies Working Group Note, (WCAG2ICT). It’s basically a task force to determine that there was only a subset of WCAG 2.0 Standards that apply to software.
Emily Lewis: [Agrees]
Jason Nakai: And they also noted that there were some changes in the standards that apply to software as well, so they put out this working group note that sort of condensed some of those that apply specifically to software.
Emily Lewis: [Agrees]
Jason Nakai: And again, guidelines are just that, they’re guidelines. They’re not hard and fast rules and a lot of it does take some interpretation of how that applies to the project that you’re working on, so there is still some of that as well.
Emily Lewis: And can I ask a question this task force, this working group, is that the federal government or is that with the Standards’ body, W3C?
Jason Nakai: All right, that’s another great question because that is specific to how W3C handled that issue.
Emily Lewis: Oh, okay.
Jason Nakai: But there are also, especially if you’re working, which I am right now, with a federal project, something that’s paid for through the government or at least has some government funding involved in it, there are federal guidelines that we have to follow that are based on the WCAG Guideline, I mean, the WCAG Standards, but they have their own set of standards that are approved by a whole different body, and this is called the United States Access Board.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Jason Nakai: And they’re the ones who make the final ruling on what the official 508 standards are for the government.
Emily Lewis: [Agrees]
Jason Nakai: And so they put out the rule, and then that’s the rule that came into effect this past January.
Emily Lewis: Right, the ADA requires that WCAG 2.0 be included in that, right?
Jason Nakai: Correct. So you can actually find this document on the Federal Register. It’s called the Information and Communication Technology (ICT) Final Standards and Guidelines.
Emily Lewis: Okay, cool. So can you highlight something that might be in there that maybe would surprise people, like that whole, “Well, the web doesn’t apply to the software situation, so we’re going to take this different approach and not consider that required guideline.”
Jason Nakai: Yes, and I don’t know if you’ve read the WCAG guidelines, and some of that, it’s very…
Emily Lewis: Of course, I have. [Laughs]
Jason Nakai: Yeah, I forgot who I was talking to for a moment.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: But, you know, some of those language isn’t that accessible to most of the people.
Emily Lewis: Yeah.
Jason Nakai: So one of the things that was surprising to me was Meaningful Sequence.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Jason Nakai: I don’t know if you all are aware of that, and basically it’s saying that any content you put on a web page should be programmatically presented in an understandable format basically.
Emily Lewis: Right.
Lea Alcantara: [Agrees]
Jason Nakai: And so that pertains heavily to web page content, which web pages are based on HTML which is based on delivering documents and basically adhere to a document-type structure, whereas software a lot of times or applications a lot of times don’t necessarily follow that same pattern.
Emily Lewis: [Agrees]
Jason Nakai: A lot of times you might be presented with sort of like a framework interface that wraps individual components inside that interface, and so there’s no real sequence of actions that you’re presented with there, so that’s one thing, and this one wasn’t actually exempted, it was just modified to make sure that whatever actions are taken does make sense.
Emily Lewis: Oh, so the individual actions within, say, like a dashboard of 12 individual actions have their own sequence.
Jason Nakai: Correct, yes, or individual components or individual process.
Emily Lewis: [Agrees]
Jason Nakai: So say if it’s a sequential process like an ordering process or an approval process, then that should have a meaningful sequence that follows that.
Emily Lewis: Interesting.
Jason Nakai: But if you’re presented with an interface just on the screen, that’s not a requirement for that.
Emily Lewis: Okay. So that’s interesting. I was not aware of that nuance. Are there any misconceptions you have come across when it comes to implementing accessibility, especially from like a developer perspective, the people who have to modify the software to implement these requirements?
Jason Nakai: Oh, yes, there are definitely some obstacles in dealing with this, but I’d say a lot of it has to deal with how accessibility is approached in the project itself.
Emily Lewis: [Agrees]
Jason Nakai: So ideally, in an ideal situation, we’d be dealing with a whole new development, so we’d be building a brand new application.
Emily Lewis: [Agrees]
Jason Nakai: And then we could choose a software on that we’ll be using or the platform that we will be building it on, we can choose in setting all the standards that we’re going to buy and we basically have control of what’s going into this application and what’s coming out of it. The big problem with dealing with large scale applications, and especially with some of these government applications or applications are used by large industries, their process, their evolution moves very, very slowly, so the life cycle or life span of an application can in that process have multiple development teams that have created multiple individual components that all get incorporated into the big application that utilizes those.
Emily Lewis: [Agrees]
Jason Nakai: And that part is probably the biggest sticking point of this, it’s having to deal with legacy framework.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Jason Nakai: So basically you’d be going in and trying to retrofit some of these accessibility requirements or guidelines on a system where it’s almost not possible to do.
Emily Lewis: [Agrees]
Jason Nakai: Then this brings up a bigger question and that becomes, “Is it more cost effective to retrofit this application or does it make more sense to rebuild it from the ground up?”
Emily Lewis: [Agrees]
Jason Nakai: And each comes along with its own benefits and its own drawbacks. One of the benefits is that going forward, it will be much more easy to maintain and it will be up to date with today’s up-to-date standards. But unfortunately, like I said, with all of these applications, especially these large scale applications, their life can span decades.
Emily Lewis: Yeah.
Jason Nakai: And it’s hard to have one team work on that throughout the whole life span and adhere to the standards and carry that throughout the project.
Emily Lewis: [Agrees]
Jason Nakai: So I’d say that’s one of the biggest issues I’ve run into in working with a larger scale applications and projects.
Emily Lewis: [Agrees]
Lea Alcantara: So regarding that, do you think that really affects the client/stakeholder perspective over what’s realistic?
Jason Nakai: Yes, it definitely affects it, and so before working with accessibility standards, like I said, have existed and have been promoted more and more lately, but at best, they are still more of an afterthought and at worst, they’re viewed as an obstacle to be navigated or avoided.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Jason Nakai: This is a big generalization for sure, but in my experience, it’s happened enough for me to comment on, and I think I understand it. If accessibility hasn’t been incorporated from the start, then technically it is sort of an add-on, and this will also then create a disruption into whatever process is already in place, so developers are used to code into a certain set of standards that aren’t made in the accessibility requirements. Once we add those in, it’s going to change those standards and they’re going to have to change the way they’re working or change the way or basically change their whole work process, and this definitely gets pushed back on that, but that can be avoided bringing accessibility into the project as a major goal from the very beginning of the plan and of the project. The biggest thing I can think of is you want to get involved in the planning process of the project as soon as you can. You want to have as much time ahead of any development cycles that begin to be able to put a plan in place and that you also start training your team.
Emily Lewis: Yeah, and getting everyone on the same page.
Jason Nakai: Yes, ideally what you would want to do is set up some standards and guidelines based on the requirements and being the person who’s sort of been tasked with that. I want to make that as easily understandable to my team, and after that, then I’ll create some reference materials for my team too so that way they can access that and keep it in the top of their mind and then I would make sure to conduct training with the entire team.
Emily Lewis: [Agrees]
Jason Nakai: This would actually be broken down into sort of like three different specific training types. One would be general for the whole team and one would be for more designer/developer focused, and then another one would be related to testing.
Emily Lewis: Before you go more into that, I’m curious, should there be training at the executive level or the decision maker level because I’m thinking about the project that we all recently worked together on. We did a college website that needed to be WCAG 2.0 AA. Lea consulted on the design and Jason and I did the front end, but Lea only consulted on the design because they had already basically bought a design from another agency, but they never talked to that agency about making the design accessible. So it was essentially like after the fact that the accessibility got brought in, and on a website, it needs to be brought in at the design phase, and I feel like in retrospect, from the start, the whole team vibe was disconnected because the marketing department had purchased this design and had gone through all of their own internal, getting approvals from the board of directors and the president of the school and all that other stuff and then they come to find out, “Oh, well, this needs to be WCAG.” And I think from that point forward, we really struggled to get buy in for accessibility even though it was part of the scope of the contract.
So I mean, I guess my point is like how do you get that stakeholder, that executive level buy-in when they might have that perspective of accessibility being an add-on or not is important and not really understanding why the approach needs to be different than that sort of bolting on at the end.
Timestamp: 00:20:11
Jason Nakai: Yes, and like I said before, that has been my experience, that has been a very hard concept to get across to not just the executive level, but everybody on the team. But luckily, like I said, it’s been my experience that right now the contracts that I’m involved with, they have taken this into consideration. It’s pretty much driven by the mandate that was issued in January that all software needs to meet these new standards put out, and so this is also very new and it’s still coming out and there are a lot of people that aren’t quite aware of all the changes that have been made, but luckily, the word has been out so there’s a lot of curious people who are seeing this and are actually reaching out to get more information on this and so that means I’ve been having a lot more meetings trying to explain some of the reasons why this is important.
But like I was telling you before, there are levels of these accessibility guidelines that are out there. There’s the WCAG one, which is from the W3C and then there’s the other that comes through the actual access board, the United States Access Board, and then the next level of chain of command would be the division or the departments. So with the current one I’m working on, that falls under the health and human services standards so they have their own set of standards that we have to follow as well, and then below that, there is the agency-level standards, which would be whoever or whatever agency underneath the health and human services department is requesting this project or this product.
Emily Lewis: And so when you have that kind of all those levels, are there competing priorities?
Jason Nakai: I wouldn’t say competing priorities, but what it does is it gives us a clear chain of command that I can actually use to go back and say, “This is why this needs to be done.”
Sponsored by
Emily Lewis: Oh.
Jason Nakai: So I can go to the very top, to the US Access Board, and say, “This is how where it pertains to the project we are working on.” But a good thing about this sort of hierarchy and chain of command is that eventually gets down to the point where what is most immediate, and what is the most immediate usually is what is contained inside the contract. So whatever is contained inside the contract for this specific product, that’s the requirements that we meet initially and then sort of branch out from there and see what other value we can add to it.
Emily Lewis: Yeah, that makes sense.
Jason Nakai: But luckily for these contracts too, there’s also a template that’s usually included with these contracts and this template is called VPAT, and the VPAT stands for Voluntary Product Accessibility Template, and basically this is a template that lists out all accessibility requirements for the project inside, it’s sort of like a spreadsheet, and what that does is it gives us a chance to then go through and address each one of those standards and say whether or not it pertains to the project. If we feel it doesn’t pertain to the project, then we need to give an explanation as to why we feel it doesn’t pertain to the project. If it does pertain to the project, then we basically lay out our plan for addressing that specific standard, so this is something that’s included into our contracts. So basically I can take that almost as a guideline that’s sort of prepackaged for us, and since this the closest as far as standards are to what we’re doing, it’s at the contract level, it’s something that I can also use sort of as an explanation to anybody on our team where I might go, “Well, it’s part of our contract so it’s requirement.” So for me, it was very important to get a grasp of what the requirements were for the contract, what was the actual wording used in the contract? How did that pertain to the next level, to the next level of standards? How did that pertain to the next level of standards and so on? So I had to basically follow that all the way up through the chain to make sure that I have the backing and I could explain to stakeholders why a certain thing was being done the way it was being done or why something needed to function the way it functions.
Emily Lewis: Yeah. So Lea, I think that kind of hierarchy or kind of a reference point of why we needed to do something is something that would be useful to think about for a web accessibility project almost extending the discovery process to include client education.
Lea Alcantara: Right.
Emily Lewis: I mean, for you, for example, the design consultation, that process, if you could describe it a little bit, it was met with a lot of resistance, your feedback on trying to make those design that had already been developed without accessibility in mind to make it more accessible.
Lea Alcantara: Right. So what was interesting about this particular project is you know the design was already accepted. At the beginning we said we might need to have changes for accessibility. I think there was a misconception though what the amount or the scale of changes would be.
Emily Lewis: Yes.
Lea Alcantara: I think they just thought we’d adjust maybe a font size here or there or like maybe one color.
Emily Lewis: Yeah, and I think we lacked the knowledge of how it important color and typeface were to them, you know?
Lea Alcantara: Right.
Emily Lewis: They had gone already through multiple approval processes to land where they were, so for us saying, “well, you just change the color,” that was a big deal to them, even though we didn’t perceive it to be.
Lea Alcantara: Yeah, absolutely, and in terms of the challenges of that, it wasn’t like we dismissed the brand cues and items. When I was doing the testing of their base brand colors in terms of contrast and if it gave me a low score, I came up with an alternative that I thought was the closest possible shade that could match, that would be a lot more accessible.
Emily Lewis: [Agrees]
Lea Alcantara: The issue is I think we underestimated how tightly invested some clients would be on specifics. Especially when it is a marketing team, they do look into the design details such as the color choices and things like that.
Emily Lewis: [Agrees]
Lea Alcantara: So I think at the very, very, very beginning, it would have been best to say that like, “Some of these changes is a larger scale than you might think.”
Emily Lewis: Right.
Lea Alcantara: And we could have also done better in maybe pushing the timelines so that could have been a little bit more thoughtful in regards to that. Not that we weren’t thoughtful, it was just more because we were tied to a specific timeline, we were obviously trying to fit that timeline so we were kind of forcing the client to accept like, “Just accept our decision,” and that caused tension.
Emily Lewis: Yeah, I definitely think so, and I think it would have been useful to kind of, as Jason was describing, how he went through the contract and identified what from the different levels or the different hierarchy of requirements applied to that contract. I think part of that process of extending our timeframe in the beginning could have included really breaking some of this stuff down for them like why are we making this choice, not just your contrast has to be – and I can’t remember the ratio off the top of my head, but your contrast has to be so and so, but what this means in terms of the accessibility to a user, and really trying to get them on board with each of the individual rule or guideline, because I felt like I kept giving them the guidelines and the IT department who was driving the accessibility investment were like, “Yeah, great, cool,” and Marketing was like, “I don’t really care that that’s guideline. What does contrast have to do with my business goals?”
Lea Alcantara: Right.
Emily Lewis: And I think that’s where we missing things because I don’t think we realized we needed to still do essentially sales, really sell the marketing department these other level of stakeholders in the project on why the accessibility was important.
Lea Alcantara: Right.
Emily Lewis: So in retrospect, I feel like we could have done something and agreed to more time and more thoughtful and considerate approach to where they were coming from.
Lea Alcantara: Right. Because I think we were coming from a point of where we, like you and I, were already invested and we knew the benefits.
Emily Lewis: Yeah.
Lea Alcantara: Just even beyond accessibility, there were certain things where it’s like, “Well, the larger font looks better to me actually just objectively beyond just making it more readable.”
Emily Lewis: Right.
Lea Alcantara: And then us, like we should always tie back to their audience and their audience goals, and it was interesting because actually, as Emily was mentioning, the IT team was already 100% on board and we should have been the one to say this, but it was the IT director who’s like, “Well, our graduate program audience is much older and they need to be able to read the information that we’re trying to send them. It’s not all like sharp-eyed 18-year-olds.”
Emily Lewis: Jason, did you have a similar experience?
Jason Nakai: Yes, actually, and just to reiterate why it’s so important to get involved in the process of the project as soon as you can, and this is in the planning phases or maybe even the preplanning phases, so basically it’s the way you incorporate these accessibility requirements or accessibility goals into the project from the very beginning. So once the team gets involved, the developers, the designers, the testers, accessibility is already played out inside the project in all the project planning so they don’t really see it as an extra step.
Emily Lewis: [Agrees]
Timestamp: 00:29:59
Jason Nakai: So one of the big, big things that I see that could help with this is the creation of standards and guidelines in conjunction with whoever your accessibility person is. That way what this gives you a chance to do is to take the requirements from the contract and you can call the hierarchical requirements that are above that as well and translate that into something that’s understandable for the team.
Emily Lewis: Yeah.
Jason Nakai: And that way you then can much easily train the team how to do what needs to be done in accessibility-friendly way without having them become defensive. It’s more of, “You know, this is just part of the project and so this is how we’re doing it,” and then you explain to them the why and the how it pertains to their particular jobs.
Emily Lewis: [Agrees]
Jason Nakai: I think a big disconnect that we’ve had recently, and it might be because a lot of these standards are just hard, or like I said, a little bit hard to read, but then there are so many out there, like who’s my real boss, that sort of thing.
Emily Lewis: [Agrees]
Lea Alcantara: Right.
Jason Nakai: So I think one thing that’s been missing is that translation of those requirements that are out there, from the standards into an actual set of standards for the project itself. You know, these are design standards. These are pattern libraries for using coding. You can have all this set up prior to the beginning of development. And if they’re already in place, then that gives the designers something to pull from and they don’t feel like you’re going in there and making changes so they’re not aligned mid-design because that’s the most costly type of fix is to try to and fix something once it’s already been started working on it. If we can get those standards and requirements into place before that work begins, then we won’t have to redo the work later down the road.
Emily Lewis: I agree with that. I feel like we tried to do that a little bit on that college website project. For example, in order to support, well, the development and testing process, I created a checklist for all of the WCAG requirements. I tried to map them to specific elements that we were building or specific pages that had certain requirements to ensure that not only when I was developing, I knew that what the requirement was for that particular component and then also when the testing phase came along. I knew all the parts that had to test out, I don’t know, but I can only know that the word is validate, but whatever the word is when you test and pass the accessibility testing, but I do feel like that’s something that also we tried to do, Jason, when we were building the JavaScript modules trying to establish the base code, the HTML, that you would then work with and translate into the JavaScript in our activity, having those components built in advance how we needed them built. We’re attempting to go that direction, but I think it could definitely have been more thought out, more well developed.
Jason Nakai: Yes, and I must commend you all on the HTML, the markup and the CSS that you all provided. I mean, that’s the one thing that’s great about working with the standards-oriented team is that this stuff is already in place. I don’t have to explain to you why accessibility is important or I don’t have to explain to Lea why contrast is important. That’s sort of where we come from; we come from building things from a standards-based approach. We take progressive enhancement very seriously so we’ve got to make sure that at the very base, it started off with the semantic HTML or markup and style and CSS is all in place and all done well, and then on top of that, then we had the JavaScript and interaction to that. So I think dealing with a smaller team, like we did, the accessibility stuff wasn’t an issue. I think the problem though was that we were coming from designs that came from a company that didn’t share the same vision of accessibility that we had.
Emily Lewis: [Agrees]
Jason Nakai: And I think if Lea was able to get a hand in that either quicker or maybe take it over, some of those issues might have been alleviated.
Emily Lewis: Yeah, definitely. So let’s talk a little bit about planning and accessibility project, really defining the phases and processes. For that school site, we pretty much followed I think what anyone would call a Waterfall approach where each phase led to the other, and I’m curious, Jason, for the healthcare project you’re working on, how has that team approached the planning process? What’s working, what hasn’t worked? Because you mentioned this was all brand new.
Jason Nakai: Yes, let’s see, apparently, like I was saying, ideally, there’s a progression of steps that I would like to follow, and that would be, again, getting in there as early as I can, understanding all of the requirements, understanding the project, its scope and its overall goals, that would be ideal. Unfortunately, in this current project, I wasn’t brought in until it had already gotten going and it got going underway, and so by the time I was completed with my onboarding and everything, development was going to begin sort of like the next week. [Laughs] So I didn’t have much time to put in any of these guidelines together. I didn’t have any time to conduct any training. I did do one very high-level training just on accessible document creation, but that’s not quite, you know, or that didn’t really pertain to the actual development of software itself.
So in that case, where I got embedded was with the testing team. Since development was going to be started in the next week, I needed to make sure that I can at the very least catch any issues in the testing phase and bring those back to the developer before that was completed. So what that means is I was absolutely involved in day-to-day weekly sprints and I was part of the testing team, and at that point, our testing team was still being built so I was doing a lot of functional testing. Since I was also the usability engineer, I was also doing usability testing, and at the same time, I was also doing the accessibility testing, and again, this was daily/weekly sprints. We had 3-week sprints, so this was very time consuming trying to sort of approach this project by like catching the tiger by the tail basically and trying to work my way up to where I could actually start getting ahead of this project rather than trying to play the catch-up role.
Emily Lewis: You mentioned sprints; does that mean it’s like following like an Agile process?
Jason Nakai: Yes, for this one, we’re following an Agile process. I wouldn’t say it’s strictly Agile because there are still some Waterfall issues that are in there, but yeah, for the most part, it is an Agile methodology that we followed.
Emily Lewis: And so in those sprints, can you describe it as like you are focused on one, not phase, but one set of functionality at a time and that set of functionality go through development then to the different levels of testing. Is that correct?
Jason Nakai: Correct. So there’s few things I need to explain a little bit, so what the sprint is, it’s basically three weeks of development and the sprint, well, we basically get an item that we’re going to work on. This would be some sort of component or maybe a change to the functionality of a component, and that would become one of our backlog items. From there, we have tasks that’s spawn off of that, and those tasks, if they actually then affect our user interface or something that a user would interact with, then that would require usability and accessibility testing. There was also quite a few of development in other types of activity going on that didn’t require usability testing or accessibility testing because that was all sort of behind-the-scenes functionality. So for the sprints, basically I would identify those that did have some sort of change or modification or addition to a user interface, and from there, those are the ones I would flag for usability and accessibility testing.
Emily Lewis: And can you explain a little bit, so the functional testing, the usability testing and the accessibility testing, they’re all separate, they’re not all done together?
Jason Nakai: Initially, the way that project started out, that’s the way it started because the testers we received were primarily just testers, functional testers, and really they do too much usability testing, but they don’t have backgrounds in that or much in accessibility so just unfortunately the way the time that I entered the project, I didn’t have time, like I said, to conduct any of that training. So I basically filled that role just to make sure I caught anything that was going on, but at the same time, I was creating the materials that I needed to then conduct the training. So now that we’re at a point where I’ve actually got that work completed, I have now started training the testers and developers to go ahead and do basically I’ve testing on how to take these guidelines of not just accessibility guidelines, but usability guidelines as well, and incorporate those into their day-to-day tasks and that gets so much more scalable than me personally trying to test every single piece of a new code that comes out. So again, like I said, this wasn’t ideal, but this is how we’re working through it.
Emily Lewis: So the ideal would be that they’re sort of doing all of the levels of testing at the same time rather than functional, then with usability, then you use to move to accessibility, but all of it together.
Jason Nakai: Yes, correct or maybe not so much all together, but I don’t think it would require a whole set of new group of testers to just come in and do that as well. Since there was already someone going in and making the functional testing and doing that, they can also be trained to also review any usability requirements that we have as well as any accessibility requirements we have and sort of add that to their testing suite.
Timestamp: 00:40:04
Emily Lewis: So you mentioned that the project you’re working on is like existing software, like a legacy system.
Jason Nakai: [Agrees]
Emily Lewis: I’m curious because so many aspects of accessibility have to do with visual experience, do you have to do any design retrofit? Have you had to make compromises on the existing design to meet accessibility or usability requirements?
Jason Nakai: As it pertains to retrofitting design, yes, there is definitely some of that. So what we’re doing is build new components to incorporate into a framework that is already there, so one thing we need to make sure to do aside from making sure that all new development is completely accessible and here’s to all of our requirements, but we also have to make sure that the users transition from the previous system into the new component isn’t completely a new experience, something that will completely throw off the user to the point where they might not even think they’re in the same system. So basically, we had to carry over a lot of the design that was already there and make it accessible in the new stuff, in the new development.
Lea Alcantara: [Agrees]
Jason Nakai: As far as our scope went for this contract, we’re not cast with going back and retrofitting the applications that were not altering, so they’re going to stay the same way they are, but we will bring in over some of the design and interaction patterns from the previous software into the new stuff to make sure that the transition for the users is as easy as possible.
Lea Alcantara: [Agrees]
Emily Lewis: Lea, what’s your opinion about sort of retrofitting a design since that kind of what you had to do with the college website? Where do you think the easiest way to make compromises is?
Lea Alcantara: Generally speaking, I think contrast in terms of font sizes I think is the easiest one to convince people.
Emily Lewis: [Agrees]
Lea Alcantara: In regards to an immediate change that actually has a pretty large impact is trying to make sure that the font contrast, whether it’s bolder or larger font sizes is pretty easy to convey, so I think that’s one of the first things that generally needs to be tackled. Also because once you’re starting to play around with font contrast and font sizing, that does affect the layout because then containers may need to change in order to adjust to that different type of font size, but generally speaking, I think that’s where it would start.
Emily Lewis: [Agrees]
Lea Alcantara: Then, of course, color is important in regards to that. Especially if there is font and color issues, that I do feel like was much harder to sell in the last college website we were discussing.
Emily Lewis: [Agrees]
Lea Alcantara: With the font sizes, they were like, “Yeah, sure, cool.” [Laughs]
Emily Lewis: [Agrees]
Lea Alcantara: But once we started diving into colors, that was where there was a little bit of tension.
Emily Lewis: [Agrees]
Lea Alcantara: But I think what could have improved talking about that is also just focusing on the easy contrast wins first as in, “Okay, we’re not going to be wading until we discuss changing entire background colors, but let’s talk about these highlight colors.” So it always seems like these little changes, right?
Emily Lewis: I agree. I think you’re totally right. I think taking it in small little increments and sort of easing them into the changes is a really smart thing…
Lea Alcantara: Right.
Emily Lewis: That we didn’t do. [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: Yeah. [Laughs]
Lea Alcantara: Yeah, yeah. It’s always in retrospect, right, because I think, as I mentioned, they took the font changes a little bit easier because they just thought, “Okay, there is a very obvious benefit to tweaking font sizes and making certain things bold and it doesn’t do major alterations to the design.” But once we’re talking about color contrast, I think maybe, again, if they were already into the type, I could have focused on, say, like, “Oh, here’s how the link colors are or here’s how hovers are.” You know?
Emily Lewis: [Agrees]
Lea Alcantara: And just focused on like the smaller portions where it could have been tweaked in sort of colors and then moving to the larger aspects like, “We did have to make major changes over back, like swaths of backgrounds, lots of…”
Emily Lewis: Yeah, I also think it’s worth noting that if you’re having to like retrofit a design that’s just got a ton of colors, it’s going to be even harder because they have a ton of colors. It’s a much bigger change than like we’re dealing with a client right now, a utility company, and we’re giving them some design feedback from an accessibility standpoint, but they have like a simple blue color palette with some green.
Lea Alcantara: Yeah.
Emily Lewis: The college website was… how many colors, fifteen?
Lea Alcantara: Yeah, fifteen, which we dropped to eight.
Jason Nakai: [Laughs] Nice.
Lea Alcantara: So that was our compromise on our end. We understand that a lot of marketing and design, I mean, I’m a designer. Of course, you want to have a lot of choice, but the way we sold that was in terms of consistency as well, which is important for branding.
Emily Lewis: [Agrees]
Lea Alcantara: And basically narrowing down the amount of color choices definitely helped with accessibility, but it was a bit of an uphill battle to get them down to that much or that little.
Emily Lewis: Yeah, yeah, and I think again in hindsight, compromise I think could have been introduced more into this project.
Lea Alcantara: Right.
Emily Lewis: Because there is a reality, at least with WCAG websites that if you do essentially an accessibility audit and identify everything you need to change and kind of put like a project timeline on it, you could plan to change something in a year, but you’ve identified it. So if you were taken to court or something, you’ve done enough diligence to demonstrate that you are taking steps to address the problem.
Lea Alcantara: Right.
Emily Lewis: And so it’s kind of like a way to compromise a little bit so you get them to pass 90% of what the WCAG requirements are, but 10% that Marketing needs more time to talk to their stakeholders or whatever, like those could have been options had we talked to the IT department about taking that sort of approach and factor that into the project because that’s also an option. I mean, ideally, you should get everything completely accessible and every page should pass, but it’s not always realistic. So a way to kind of cover your butt is to do that full audit, identify everything that needs to be changed and then essentially prioritize them and put time frames on them, like have an actual document that’s available in case anyone were to ask because that’s kind of a way to get you part of the way there if you’re having a hard time with buy-in, especially like with they’ve already invested in a design.
Jason Nakai: Yes. Well, this is actually a big theme that’s being utilized by me right now actually. Sort of the way the language has stated for the new standards is any alteration or new development has to follow those standards. So you still have that grace period, I think it’s what it’s called, an exemption almost of anything that’s already been built prior to these requirements don’t necessarily need to be updated until they’re altered in any way.
Emily Lewis: Yes.
Jason Nakai: So from what I’m doing right now is we’re building new components to put into an existing system so those new components that we’re building definitely have to meet those accessibility requirements, but the actual system that we’re plugging those into does not have to, because we’re not changing it. We’re basically just adding something to an existing framework. However, I’m trying to figure out this and I’m trying to figure out a best way to approach this is that the steps required to go through that framework to access our new components that we’re building, how do I make those accessible, and so that’s a bit of a problem.
Emily Lewis: [Agrees]
Jason Nakai: So for that, that’s what I’ve been saying, “We’ve identified this problem, we are going to take these steps to try and rectify that problem. I mean, it’s still an issue now, but we know about it and we’re working on it.” [Laughs]
Emily Lewis: Yeah, I definitely think that’s something that we could have probably used to our benefit a little bit, Lea, in retrospect, of course. [Laughs]
Lea Alcantara: Right, right, right.
Emily Lewis: You know, Lea, let’s talk a little bit about – I generally feel like we’ve addressed the design aspect and I think it’s been interesting to have the comparison of how Jason’s project is doing a little bit Agile where we took more Waterfall. I feel like the actual development on the college site was pretty straightforward; build HTML and CSS, add some JavaScript, kind of standard progressive enhancement, but I feel like where we hit another challenge that in hindsight I think we could have done better at was essentially what we called the client handover when we’re handing over the system to them. We’ve done our QA and testing and now we’re handing this system over to the client and it’s not just the front end but also the CMS where they have to make their content accessible.
Lea Alcantara: Right.
Emily Lewis: And I feel like we should have talked a lot more about that in the beginning.
Lea Alcantara: [Agrees]
Emily Lewis: Because I don’t think they were prepared for it at the end.
Lea Alcantara: Yeah, absolutely. Again, I think part of it is because we were all in our own heads over like, “This is how it’s going to be and they’re just going to accept it.” [Laughs] And that’s not always the case. That being said though, it’s interesting I think, just in terms of communication, sales and just explaining stuff, one of the benefits of us being part of the CMS build and having accessibility in mind is that we can essentially give them rules and restrict certain things in order for them to, by almost default, comply with accessibility standards.
Emily Lewis: Right. For example…
Lea Alcantara: So for example, the simplest thing, ALT tags in images, right?
Timestamp: 00:50:05
Emily Lewis: [Agrees]
Lea Alcantara: And the system that we used, which was Craft CMS, you can attach fields to assets like images and what I did was basically added an alt text field and made it required.
Emily Lewis: [Agrees]
Lea Alcantara: And so every time they upload a new image, they just literally have to add an alt text field.
Emily Lewis: [Agrees]
Lea Alcantara: Otherwise, it will be like, “Warning, there is no alt text attached to this asset you just uploaded.” Right?
Emily Lewis: [Agrees]
Lea Alcantara: So that’s really one simple thing, and then on top of that, I changed the listing view of all their assets to make sure that they see the alt text field.
Emily Lewis: [Agrees]
Lea Alcantara: So they can see at a glance when they’re just looking at all their images, which images don’t have alt text and which do.
Emily Lewis: [Agrees]
Lea Alcantara: So they could just do a mass review and just mass add based on that as well, so that’s like one simple thing you could do within a CMS.
Emily Lewis: Yeah. I feel like we did as much as we could have done with the CMS to kind of set them up for success.
Lea Alcantara: [Agrees]
Emily Lewis: But I think the biggest challenge that we saw is they just were not prepared for how much work they needed to do on their end.
Lea Alcantara: Work, yeah. Yeah, expectations.
Emily Lewis: Yeah, if you manage a website for a number of years, you’ve got a hundred images.
Lea Alcantara: Yeah.
Emily Lewis: And what if they never ever add alt text, so that’s a hundred images that are going to be in the new site, it’s just a redesign, it’s not like they’re getting rid of stuff that has to be updated.
Lea Alcantara: Right.
Emily Lewis: Or this was site was five years ago and they have some tables for layout and you can’t do that in WCAG.
Lea Alcantara: Yeah, right.
Emily Lewis: And that those were not in CMS templates, but rather hardcoded HTML in a WYSIWYG entry.
Lea Alcantara: Right.
Emily Lewis: So they had to go into every single entry and make sure that everything was updated.
Lea Alcantara: Yeah.
Emily Lewis: We created a spreadsheet that said, “This is an old pattern that you have on these types of pages and this is the new pattern you need to follow that’s accessible.”
Lea Alcantara: Right.
Emily Lewis: But we just gave them one example of each, not like an entire matrix of on every page, and frankly, that’s what they needed.
Lea Alcantara: Right.
Emily Lewis: They needed a huge matrix of all the pages that they needed to touch.
Lea Alcantara: Right.
Emily Lewis: Because it just got quickly out of hand I think in terms of them feeling overwhelming, overwhelmed rather.
Lea Alcantara: Right, right.
Emily Lewis: Also, I don’t think they had a good process for their own accountability or due diligence. How many times did we get issues that were already in the queue, but no one on their team were talking to each other kind of thing.
Lea Alcantara: Right, right.
Emily Lewis: So I do think we could have done something different with the client handover and setting expectations across the board.
Lea Alcantara: Yeah, absolutely, and/or if this is something that we had set expectations at the beginning and they were like, “Nope, we don’t have bandwidth for that.”
Emily Lewis: Right, yes.
Lea Alcantara: Then we could have…
Emily Lewis: Compromised…
Lea Alcantara: Or built into the project budget or timeline extensions in order for another team to do those mass ALT tag changes, mass table changes, et cetera and so forth, right?
Emily Lewis: [Agrees]
Lea Alcantara: Because there are just so many like, “What about this? What about that?” that they weren’t prepared internally as a small team to just do, and we also had a really rigid timeline, I think, so that really affected things.
Emily Lewis: [Agrees]
Lea Alcantara: If we had also set expectations that we will need to potentially expand to accommodate, then, you know.
Emily Lewis: [Agrees]
Lea Alcantara: Again, in retrospect. [Laughs]
Emily Lewis: Yeah, I feel like one of the few things, so Lea and I have an internal project retrospective and then we have one with a client, and one of the things I feel almost certain about moving forward is that if we get another project of this size and scope, this is a very large project, it involved multiple sites, the client had the budget, we should have gone onsite in the beginning and done a lot of handholding about to set those expectations to do the education.
Lea Alcantara: Right.
Emily Lewis: And we would have gone onsite at the handover at the end to assist them in that.
Lea Alcantara: Right, right.
Emily Lewis: And I almost feel like no matter what, if it’s a project like this, that is part of the project and that adds on a whole month, maybe two months to the overall project in order to get that complete client buy-in, setting expectations, because we knew what we needed to do.
Lea Alcantara: Right.
Emily Lewis: I think where things feel apart is the client didn’t fully understand what they needed to do.
Lea Alcantara: They didn’t know. Yeah, right, because I think we told them that they needed to do certain things, but we didn’t communicate properly the extent and scope.
Emily Lewis: Yeah. So Jason, do you have similar problems, like let’s a little bit about testing. Especially when you kind of got brought in at the end and you were trying to do all the accessibility on your own, had there been some lessons learned about how to best approach to set your development team’s expectations, the testers’ expectations or anything like that?
Jason Nakai: Most definitely, and again, I sound like a broken record, but you want to get involved with the process as soon as possible.
Emily Lewis: [Agrees]
Jason Nakai: So that again you are introducing these accessibility concerns from the very beginning so they get woven into the project as opposed to something that’s added on.
Emily Lewis: [Agrees]
Jason Nakai: But big thing for us is we really need and we utilized an issue tracker.
Emily Lewis: Oh.
Lea Alcantara: [Agrees]
Jason Nakai: And it doesn’t really have to be super fancy issue tracker, but it shouldn’t be Post It notes or email threads because those things are so hard to follow up on and they inevitably fall through the cracks.
Emily Lewis: [Agrees]
Jason Nakai: So for us, we’re using Agile development methodology, and through that, we’re actually using Microsoft Visual Studio Team Services as sort of our project management software, and in there we can actually utilize something for issue tracking, and since everybody at that project has access to that, we know where things are at and we know when things get either resolved or when they need to be escalated or if they no longer even an issue anymore, so we can actually see in real time visualization of where those issues are at.
Emily Lewis: I think that’s a good point. Lea, you and I really sort of struggled on what the best approach for this was because one of our key client’s testers and person responsible for updating content in the CMS is a bit on the less techie side.
Lea Alcantara: Right.
Emily Lewis: So we wanted something that was as kind of the lowest common denominator, anyone could use it as possible, but I don’t think it worked as well, yet at the same time I’m not really confident an issue tracker would have been any better.
Lea Alcantara: Well, it’s one of those things where tools are interesting because certain people log onto it and absolutely love a specific one and the other one just don’t resonate as well. Some people still love email in comparison to other project management tools. So I don’t know, like I think it really depends on the particular client at the end of the day, and again, one of those retrospect things, maybe we really need to take more seriously the idea of technical acuity of the client that we’re dealing with and then adjust, really adjust from there.
Emily Lewis: Yeah, absolutely. I mean, I feel like we totally ate it on the project management of the testing phase.
Lea Alcantara: Right.
Emily Lewis: Because there was just so much, “Nope, you’ve already reported that one. We’re already working on it, and you need to check with your teammate to make sure you guys are talking first,” and yeah.
Lea Alcantara: “FYI, it’s in the documentation already.” [Laughs]
Emily Lewis: Oh, my God. That was like Lea had to do, “Please refer to the documentation.”
Jason Nakai: [Laughs]
Emily Lewis: “Please refer to the documentation.” [Laughs]
Lea Alcantara: [Laughs]
Jason Nakai: Well, just to touch briefly on another topic that sort of pertains to this, so like I said, I joined the project a bit late and so development was already starting, so I jumped into the testing area so that way I could catch any accessibility issues that might have already made it through the development process. But one thing that was key for me to start to get in ahead of that instead of always being on the back end was to start attending design review meetings and other meetings such as that.
Emily Lewis: Oh.
Lea Alcantara: Right.
Jason Nakai: So I could actually bring up these concerns at the very beginning of something when a design was just sort of actually gathering its requirements. I could bring up an issue with, “Oh, did you make sure to check font sizes or to check contrast ratios of certain things.” Luckily with these government applications, people aren’t really set in stone on design. [Laughs]
Emily Lewis: [Agrees]
Jason Nakai: People don’t really fight tooth and nail for design like they would on some other projects I’ve been on. So from that perspective, it’s a little bit easier to do that.
Emily Lewis: Yeah. So before we wrap up, because this has been a pretty involved conversation, I did want to talk a little bit about like maintenance. So one of the things I think is important to keep in mind for a project, in a web accessibility project, is keeping the client aware that there’s a maintenance aspect to this, particularly when they’re dealing with the CMS where they have a lot of control of the content. Lea and I, in our Demystifying Web Maintenance episode, we talked about doing like an accessibility site audit. It could be something that’s like a monthly review of the site using browser-based testing tools so that you’re making sure that any new content added to the CMS in the previous month still passes the requirements, and it’s something that the client can do themselves or it’s something that we as the developers can provide them if they don’t have the resources or the staff to handle it themselves. I definitely think it’s something that is important because if it’s not done and content gets inaccessible, then all that time and money that they spent on getting everything accessible goes away because the reality is it’s pass fail. If one thing on the page doesn’t pass, the whole page doesn’t pass.
Timestamp: 01:00:03
Lea Alcantara: [Agrees]
Emily Lewis: So in terms of that aspect of maintenance, Jason, is that where that library — the standards library — that you are creating comes in to play?
Jason Nakai: Yes, it definitely just comes into play in there, and that’s just a sort of a pattern repository. These are patterns that we have already used and have tested and have been approved to be usable and accessible, so we’ll just put those in a repository. Whenever somebody encounters a need for one of those, they can just pull it out and use it. With that, I feel pretty comfortable that it doesn’t have any accessibility or usability issues.
Emily Lewis: Do you do any kind of like audit or like when something has gone through the sprint, is it is just done or does it get audited later?
Jason Nakai: So for that, like I said, if we do any in-sprint testing, so once a piece is complete, it goes to functional testing, a usability testing and accessibility testing before that cast gets marked complete for the sprint. After all of that is done, then we’re going to do another phase of testing during the user acceptance testing, and that’s just again to make sure that the end product is meeting the standards that were laid out in the contract.
Lea Alcantara: So this has been a really in-depth conversation. Can you give us any final tips for making an accessibility project smooth and successful?
Jason Nakai: Well, actually, again, if I can just reiterate some of the things I said before, one, that’s to get involved in the project as soon as you can. Two, make sure you try and train your team on this, on these concepts, so that way it becomes a team issue rather than you trying to come in and get involved after the fact. Definitely, continue to learn on these things, because like I said, there are so many standards out there that a lot of teams are changing, but they’ll give you notification on what the upcoming changes are, and so it’s always good to keep on top of that. And then lastly I’d say ask for guidance. If there’s something you’re not fully understanding or aware of, reach out to somebody, a peer or maybe someone who’s an authority on this subject and ask them for guidance and direction they can point you in because it’s been my experience that there’s a lot of information out there, but a lot of it isn’t very distinctive and clear. It doesn’t really give you a distinct direction to go.
Lea Alcantara: [Agrees]
Jason Nakai: So for me, I found it very valuable to reach out to people who have been doing this for a long time as well and to get other perspectives on it.
Emily Lewis: Did you come across any good resources that did convey this stuff clearly?
Jason Nakai: Oh, like I said, they’re all over the place. There’s a bunch of blogs, just people who are really looking into this, but I would basically go on to some of these. Like the United States Access Board website, they have a lot of articles that pertain to accessibility or stuff going on at the moment. It’s same with the W3C, I try and keep an eye on some of those things that are coming out from there, and then of course, I follow a bunch of accessibility and usability people on Twitter. I also just keep a finger on the pulse of what’s going on out there.
Emily Lewis: I would just chime in that I do think the W3C Web Accessibility Initiative is a really useful website. They have actual patterns that you can follow to build accessible components including they have a whole section on interactive components like how you’re underlying HTML should be structured to support accessible tabs or something like that. So the Web Accessibility Initiative is a really good resource.
Jason Nakai: Yes, and that’s actually where I got sort of the inspiration for incorporating that pattern library into our processes because I definitely wanted to train the developers in how to develop with accessibility and usability in mind, but sometimes it’s hard for them to keep that top of mind, especially if it’s not something they’ve done for throughout their career.
Emily Lewis: [Agrees]
Jason Nakai: So if you can get something like this, set up a little repository of these patterns that they can refer to, then there’s a refresher for them right there at their fingertips.
Lea Alcantara: Very cool. So that’s all the time we have for today. But before we finish up, we’ve got our rapid fire ten questions so our listeners can get to know you a bit better.
Jason Nakai: Okay.
Lea Alcantara: Are you ready, Jason?
Jason Nakai: I think so.
Emily Lewis: [Laughs]
Lea Alcantara: Okay, first question, what’s your go-to karaoke song?
Jason Nakai: That would have to be the song from Annie. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: Tomorrow?
Jason Nakai: The sun will come out tomorrow…
Emily Lewis: [Laughs]
Lea Alcantara: Nice. [Laughs]
Jason Nakai: Actually, I have a funny story about that. I was traveling, I went to Brooklyn, some of our friends took us out to a karaoke bar and we’re waiting to sign up, be the first people to sign up, and somebody signed up right before me and he actually chose that song. [Laughs]
Emily Lewis: [Laughs]
Jason Nakai: It was odd that the first two people want to sing the same song.
Emily Lewis: What advice would you give your younger self?
Jason Nakai: I would give my younger self the advice to not be afraid to fail, that to try and fail as much as you can, because that’s one way you can learn. For me failure as a younger person was so hard to deal with, and I think it just built it up in my head.
Emily Lewis: [Agrees]
Jason Nakai: So if you can learn to accept failure and learn from it and then take that in and realize that just one failure is not the end of everything, but it’s an opportunity to learn.
Lea Alcantara: What’s your favorite PG-rated curse word?
Jason Nakai: Oh goodness, did you hear that? That’s the one that always comes out. In fact, Emily can probably attest to this. I have a bunch of them. I think good grief would probably be the biggest one.
Emily Lewis: He could do the Charlie Brown good grief. [Laughs]
Lea Alcantara: Good grief, I love it. [Laughs]
Emily Lewis: All right, who is your favorite superhero?
Jason Nakai: Oh, that one is another hard one, but I think right now, being with my race coming up, I’d have to say The Flash.
Lea Alcantara: What is your favorite time of the year?
Jason Nakai: Oh, that would be fall. I’d say fall would be my favorite time of the year.
Emily Lewis: If you can change one thing about the web, what would it be?
Jason Nakai: Oh, my goodness. I think what I would change about the web is I would want to make it more like the cyberspace reality that was described in William Gibson’s novels. To me, it would always be cool to see sort of the way it played out in a physical way.
Emily Lewis: Cool.
Lea Alcantara: What are three words that describe you?
Jason Nakai: I’d have to say I am curious, I am passionate about things and I get obsessed about things. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: What are three words that describe your work?
Jason Nakai: My work, I’d say it has to be important to me, it has to be fun to me, and it has to allow me the freedom to explore new things.
Lea Alcantara: What’s your favorite meal of the day?
Jason Nakai: My favorite meal of the day would be – oh that’s a hard one because I must admit, Emily is a great cook, so dinners are always amazing.
Emily Lewis: [Laughs]
Jason Nakai: But I recently started liking breakfast more and more.
Emily Lewis: All right, last question, coffee or tea?
Jason Nakai: I’d say both. I actually drink coffee all day long.
Lea Alcantara: [Laughs]
Jason Nakai: But I also drink tea. In fact, my first cup of coffee in the morning is coffee mixed with a bit of mushroom tea.
Lea Alcantara: Very cool. That’s all the time we have for today. Thanks for joining the show.
Jason Nakai: Thank you very much. I enjoyed the show and I enjoyed being on it.
Emily Lewis: In case our listeners want to follow up with you, where can they find you online?
Jason Nakai: Well, you can find me on Twitter at @jnakai, and I think that’s basically the only place I’m available right now. [Laughs]
[Music starts]
Emily Lewis: [Laughs] Okay, thanks again, Jason, this was really great conversation.
Jason Nakai: It’s great. It’s very nice to speak to the two of you.
Lea Alcantara: CTRL+CLICK is produced by Bright Umbrella, a web services agency invested in education and social good. Today’s podcast would not be possible without the support of this episode’s sponsors! Many thanks to the Performance Matters Conference and Focus Lab! Don’t forget to buy a shirt to support the people of Puerto Rico.
Emily Lewis: We’d also like to thank our hosting partner: Arcustech.
Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about CTRL+CLICK, make sure you follow us on Twitter @ctrlclickcast or visit our website, ctrlclickcast.com. And if you liked this episode, please give us a review on Stitcher or Apple Podcast or both! Links are in our show notes and on our site.
Emily Lewis: Don’t forget to tune in to our next episode when we dive into project management with Rachel Gertz. Be sure to check out ctrlclickcast.com/schedule for more upcoming topics.
Lea Alcantara: This is Lea Alcantara …
Emily Lewis: And Emily Lewis …
Lea Alcantara: Signing off for CTRL+CLICK CAST. See you next time!
Emily Lewis: Cheers!
[Music stops]
Timestamp: 01:08:40
