Transcript

I'm excited to share with everyone today about our work in developing an affordable housing platform in the Bay Area, and how I, along with the rest of my team worked in a way where we actively did a lot of community outreach with our community partners to make a product that was accessible as possible to as many people as possible. So one question I try to ask myself as a designer and a member of a team that delivers products that have social impact is, how do we build our products to be accessible for all users? We at Exygy are a B Corporation and so the products that we take on a regular basis are products that are targeted to serving marginalized communities in some way and delivering in a way that they're creating positive change in people's lives.

And so one aspect of that is making sure that those products deliver and are usable by people with disabilities. So by way of introduction, I'm going to talk about one project that we have done in the last six years. And how that project grew and how that project allowed us as a team to establish an accessibility playbook that we use across all of our products. And it was because of how deep this product went into working with the community members. It allowed us to really test a lot of things and get beyond what you might do, if you just do a Google search about accessibility and actually talk to real people about the solutions and the things that are really going to help them. So just a little bit about the product, Exygy has been working with various communities for the past again, five years to build a one stop shop for housing related needs and there's four pieces to the product that we've developed.

It centralizes affordable housing resources, so that there's one place you go for all affordable housing listings. It makes the application process as easy and equitable as possible to as many people as possible. And on the developer side of things, the housing developer side, it makes their process of managing that experience for the applicants as smooth as possible while reducing costs and taking look at some existing third party tools that they're already using and complimenting those workflows. And finally, we started in San Francisco, we moved into San Mateo County, San Jose and Alameda. And in that process are collecting a lot of data about a lot of people and feeding that to the region, so that the Bay Area in general and California is getting smarter about the housing opportunities that people actually need. And not keeping that knowledge bucketed in one county, one region in California.

So again, just to step back, just do a little bit more storytelling around the housing product before we get into the accessibility work. So we started in 2016, we worked with the San Francisco mayor's office of affordable or housing and community development to take a look at a product or process that was on paper. That was being done a dozen different ways by dozens of different agencies and was really opaque and people really didn't have access. It was just really hard for somebody who needed affordable housing to find a valid opportunity for a unit that was available and submit their application, find out if they were accepted and what happens next. And so we took that very distributed, decentralized process and made it a purely digital process that folks could do in 20 minutes. They could log on, choose to create an account or not create an account and apply for an affordable housing opportunity.

And then since it's inception, the site's been vastly popular and in San Francisco alone has gotten 5 million folks have been served. And then over 100 households per month are actually being housed in affordable housing units because of the portal there. Since 2017, based on the success in San Francisco, we've developed relationships in San Mateo County and San Jose and Alameda County and found that we had to take some of the policies and decisions that were made in one jurisdiction in one county and go out and knock on a lot of doors and meet a lot of people. And have a lot of conversations again about how their data model and their public policy around affordable housing, how that fit and compared with the work we did in San Francisco, so that we could make a solution that everybody could use. And then develop a code base that is open source. We now have folks in Detroit and are talking with people across the country about how to set up Bloom code bases in any number of locations across the country.

So that's a bit about the product but the stuff that I think we're here to talk about today is accessibility, right? And so one thing that I found, I did a lot of the user testing and user research for this project in the first few years. And at the most rapid state of user testing, we were out there every two weeks sitting down with veterans, people with disabilities, homeless and nearly homeless people, just various communities, non-English speakers and finding out how they were going to use the website in order to accomplish a task. And I think the thing that you find out especially about housing, is it's a very human issue. It puts people in a very vulnerable place when they're trying to find a place to house their family.

And so it left us with the principle that we needed to be very intentional about the decisions that we were making, and we really needed to maintain ongoing relationships with the people that we were trying to design solutions for. And as part of that work, we developed a set of accessibility standards that now all of the products at Exygy tried to base their work on, both design and engineering. And in content design, the actual words that you read and make that accessible for everybody. And we'll talk about this in a little bit is that, the work that you do in design and technology to make something accessible to somebody with a disability, is actually just making your product better. It's applying structure. It's applying semantics. It's applying just intuitive best practices to your product.

And by serving folks who are traditionally underserved, you're actually making something that's easier and easier to use by everybody. And so I'm not sure, hopefully a lot of this isn't redundant but we'll just get into definition of accessibility or how we define accessibility in the communities that we serve. With some of our design and technical solutions, there's four categories of user and community that we focus on when designing for accessibility, visual, hearing, physical and cognitive. There's a wide range of ability to disability across that spectrum. To be somebody who's just nearsighted or farsighted, to severe or somebody who's completely blind. And the solutions that we put in place seek to serve as wide a range as possible of those people. And when it comes to the types of solutions that we're looking for, just some numbers; 28% of the world's population has some visual impairment that's going to be benefit from accessibility solutions.

5% of the world's population has some sort of hearing impairment that's going to benefit from these things that we're doing. 16% of adults in the U.S. have some type of physical impairment that's going to benefit. And finally, 8 million people in the U.S. have some form of cognitive disability that's going to benefit. And the types of solutions change based on the community that you're seeking to serve or your product may focus on a specific silo of this community. I don't think there's a rule that says you have to equally serve all of these folks. And based on your user research on the people you're trying to serve, you may need to prioritize different aspects of this overall ecosystem. But the types of solutions are different for each use case. And for visual, we're looking at contrast and structure, so text size, text weight, color combinations.

And then on the structure side of things, a predictable layout, clear hierarchy and making sure your content is scalable. Those things are all going to serve folks with visual impairments. When it comes to hearing, anytime you can pair audio with any feedback you're getting in a browser is going to assist that community. And when it comes to physical disabilities, you're looking at operability. Meaning that these folks aren't using your standard mouse and keyboard solutions, they're using assisted technology to access your products in your websites and so whatever you come up with needs to meet that criteria. And finally, when it comes to cognitive disabilities, the things you want to be looking for to solve problems are organizing your content. A strong hierarchy highlighting focus, where somebody is on the page and just clear and simple tasks. Breaking out long tasks into simple step by step processes are going to reduce the cognitive load on somebody who's trying to access your service.

And like I mentioned earlier, accessibility helps everybody but the types of things that you're going to put in place to make your website serve people with disabilities are going to serve more and more people. For example, if I have a slow internet connection, my content is going to load before my CSS loads. So I'm just going to get structured text on the page. And if I take my time as a designer and a developer to make sure I've structured my content with clear headings, somebody is still going to be able to get the gist of the content, they're still going to be able to accomplish a task. So those things that we put in place to assist somebody with a cognitive disability are going to help somebody who just has bad internet. Situational limitations, such as anytime your senses are compromised such as bright sunlight or being in a loud environment.

Those tools that we put in place for people with visual impairments or hearing impairments are going to help you when you're just in your car and the sun's really bright. So those things are going to help more and more people. And finally, temporally disabilities, everybody breaks a finger, an arm or loses their glasses or breaks their glasses. And in those instances, those things we've put in place for visual impairments for those people with physical disabilities, they're going to come and be useful at those times. And finally, with alternative devices, smart watches or TVs, like when your screen is being stretched really big or shrunk really small and when I just don't have a mouse. If you put into place keyboard accessibility, which will get into in a second. Which allows you to scan your content, those devices are going to pick up on that and all of a sudden you have a website that's accessible on alternate devices, because you prioritized meeting the needs of somebody who needs to use a keyboard.

So again, I wanted to take a minute to look at some of the more technical stuff that we do, sort of a checklist that we have when we kick off projects and as we work on projects that serves as our baseline of accessibility. We, like most folks based the work that we do on the Web Content Accessibility Guidelines in section 508. And four big things that make our front line of accessibility are keyboard access. All interactions on that website need to be available via arrows and tab keys and the space bar. And it's not that everybody has a keyboard, it's because assistive technology devices are programmed to use those inputs to do the things that they need to do.

So the keyboard is the way that we're testing those inputs, but those inputs are being leveraged by more complex technology and helping people with physical disabilities. And then when it comes to text hierarchy, also really critical. Really front of mind for us is the example I talked about before, is really making sure your content is structured in a way where your H1 becomes before your H2 before your H3 and that content is really nested appropriately. If you've ever seen a person use a cell phone, who's using a screen reader, they can choose the different ways they scan content. You can either scan by scanning the links on a page or you can scan by text and it's the same way you read the outline or table of contents of a document. So they're going to scan your content and get a gist of the types of content that you have on your page, find the content that they want and then select that section of content to read more.

But in order for that to work properly you need to do the work to make sure your headings are nested appropriately for that to happen. Next up is forms. Most of the things that we do every day on the internet involve some kind of form, email sign up or more complex registration forms. And there's all kinds of things that you can do to make sure that your forms are reachable, capable by the keyboard. And then when something goes wrong, when there's an error a user needs to know something went wrong and what to do to fix it. And they might not be able to see your screen and so you need to be able to use the proper aria labeling and form conventions to make sure that any instructions or error messages connect to that form input so that person doesn't get lost or trapped and they can fix something and move through your website, the same way that somebody who has the benefit of sight can also make that change based on the error messages you probably have on the website.

And then finally the last thing that is crucial to make sure we reach as many people as possible is color contrast. There are lots of tools that do this, your visual designers can do this really early on, just to make sure the color combinations that they're using have sufficient contrast, push the text in the backgrounds. There are automated tools you can use in your development environment to make sure this is done consistently. And there's even new CSS properties that you can do or you can apply to your HTML on your styles, so that if this stuff gets changed dynamically your website can be smart enough to change the color so that there's sufficient contrast ratio based on whatever dynamic event happened in the browser. So all of that stuff is very boilerplate and baseline for us to get started.

I did want to touch on how accessibility grows into other ways of meeting the needs of people. Accessibility has been around for a long time and I think its grown into this idea of inclusive design. And inclusive design is an umbrella term where you're making sure that the solutions you're coming up with and the problems that you're solving are meeting a full range of human diversity. And that means meeting the needs of people who might otherwise be marginalized or underserved. One example of that, that's fairly straightforward is language access. So if you're trying to meet the needs of more and more people, making sure that your content in your website and your forms are accessible to non-English speakers or monolingual users is critical. It's something that we learned a lot about on the housing world. You're traditionally working with housing counselors who speak their language but we wanted to make sure that our tool did a lot of those things.

One big consideration is that each jurisdiction in the Bay Area, prioritizes different communities. So San Francisco has four languages that it serves by default. Alameda County actually has a subtly different set of languages. And we're seeing that each county based on its constituency is going to change the communities that it prioritizes and serves. And so we built the system to ensure that happens. We use a combination of manual translations where we actually hire a person to come in and translate the copy for static text, text that's common across all the listings are all housing policy. But from listing to listing, things change and so we can't always get a manual translation in time for a listing to go up, so we use Google translate in those instances to fill in the gaps so that we have some baseline of language translation happening.

And for all of that it's not perfect, right? Even if we have somebody who comes in and translates this based on the dictionary definition of the word, there's a lot of context that is subtle when it comes to language translation and the dictionary definition translation doesn't always work. So what we've had to do is continue to reach out to housing counselors who serve these communities and have them read through our texts to make sure that within the housing context that these terms still apply and that we are using the appropriate ones. And so it's an iterative process that we're consistently learning and having those partners in the community just act as one more fail safe to make sure that we don't alienate anybody or push anybody out.

So having those relationships is really critical for us, being on the ground with users and maintaining partnerships. And I'll just overview what that process looks like. In the beginning we have these folks that we work with represent these different communities, either language based or ability based communities. And we sit down with them really early on and we ask them, in broad strokes is what we're thinking of really going to solve the problem? And they've let us know what works and what doesn't work. Then our visual designers have an idea and they start to sketch it out. And they're using visual accessibility tools, such as color contrast in the design mockups to make sure that we have sufficient visual contrast. That moves over to the product team and the product team writes the stories for the engineering team to build.

And they're going to put the accessibility criteria into the user story. Based on the W3C, they're actually going to put in what this component needs to do in the browser and how a keyboard user is going to access this component. So that when the developer picks it up it's very explicit to them what they need to do. They're assigning a contract to make this component as accessible as possible. The developer and the engineer have automated tools that they're using to parse the code that they're writing, just to make sure that it's linted and we use a tool called App X which makes sure all of our components are meeting that same checklist of accessibility. But even technology again has its limits and so we have to do a manual QA browsing after the fact and need the keyboard test everything.

And then we have to have another step where we actually reach out to the community members who use these tools every day to make sure that... We're not professional screen reader users, we don't know really, all the nuances of jaws and voiceover. We need people who use this stuff to tell us and then there's another step they feed that feedback back. And so two relationships that we built in San Francisco that were super useful, one was with Lighthouse for the Blind. We met them through with the Mayor's Office and they worked with us from the beginning again, in that first date. They were just there to look at our broad strokes, plan and tell us the things that we needed to be aware of when serving people with visual impairments. We next sat down with experts on their team, they actually have people at Lighthouse whose job it is to test websites and test apps to make sure that they work for people.

And we got a lot of really great feedback from them early on, especially around our short form application. We had a lot of error messages that weren't working. We had some keyboard trapped where people were getting lost and they really helped us get rid of those traps to make sure that everybody could use that application. And then as the features matured we continued to work with them and they have a program actually at Lighthouse, which is really cool where they actually train young people to become accessibility experts. So they are training people who have visual impairments to become professional accessibility experts, so they can be paid to use the technology they use every day to ensure products are more and more accessible to more people.

So that was a pretty rewarding process. And then finally, we met with The Arc in San Francisco, who serves families with members with developmental disabilities and cognitive disabilities. And they gave us three big principles that we used throughout the application and website. One is to make everything clear and simple. We have a short form application that we break up into steps and they encouraged us, anytime there was a complex question to really pear that down to where somebody only has to think about a yes or no option. Because people with cognitive disabilities really need to focus on one task at a time. They continually encouraged us to readdress the reading level to make sure that the text was as clear as possible and was just enough to get the job done. And then finally empty space, which might seem simple but the more you provide space around your interfaces and allow people to focus on one task or one button, a one form element at a time is less daunting.

It allows people to get the things done if they need to get done. And so the general impact of the platform has been pretty nice to see and I think we credit a lot of that with the accessibility changes that we made. We reached 600,000 online applications, we have 97 plus percentile when it comes to applying online versus applying via paper. And again having 5 million folks in San Francisco alone be able to use the product is a great milestone. So just in summary, some of the things that really helped us and make us a better product team, and we credit were three pieces. Being accessible from the start, really developing relationships to partners and experts in this stuff and co-owning these decisions. Testing with real people and not relying solely on technology to make these decisions for you. And then building into your process, like I showed you before. Making sure that every member of your team carries some of this burden, means that nobody's the bottleneck is really going to ensure that there's less stress in your team.

This becomes a principle or an ideal everybody's using and it's something that at the end of the day you can all put a pin in. I can share this link, if anybody's interested I put together just a set of resources that anybody can use to foster more inclusive design in their products. There's six pieces of this and it's not just accessibility. There are tools out there such as the WebAIM has a keyboard access instructions. How you, as a person who doesn't use a screen reader can do all the testing via keyboard to ensure that people with screen readers can use your product. A color contrast tool that allows you to input any two colors and gives you a grade on those colors. Google has a page speed test tool where you can put your URL in there and it'll tell you how well you're serving people with limited bandwidth, so you're reaching more and more people. Flesch-Kincaid has a readability tool where you can put in a URL and they give you back a score for the complexity of the text that you're communicating to your visitors.

This is more progressive, Intuit has actually taken a step further and promotes as we do as well, moving towards anti-racist vocabulary on your products. Moving away from a lot of terms that were invented in the past, that actually cause more harm than good and moving towards more inclusive language to broaden your audience. And then finally, a digital literacy is this idea that just good, intuitive design practices can help people who might be intimidated by technology, who might have cognitive disabilities, and there are things you can do just as a designer when planning how to build something and there's a resource there for folks to use as well. Please feel free to reach out, give us an email. You can sign up for our newsletter to find out more about the housing project or you can reach out to us on social media if you have any other questions.

Have more questions or want to chat more about accessibility for human-centered digital products? Continue the conversation with Jesse at jesse.james@exygy.com !