Transcript: “Good Hackathons vs. Hackathons for Good”

Transcript

We are going to switch over to our keynote speaker, Josh Miele, Josh is… I think… qualifies as a good friend of mine at this point. He’s also a amazing innovator. He leads the Center for Accessibility and Open Source, um, and is a MacArthur “Genius” award winner among many others accolades. 

He’s got a Ph.D. in acoustic psychology… or psychoaccoustics. There, I got it right. Okay, um… he also works on accessibility at Amazon. And I’m probably missing other important things that he does. 

But he is the innovator behind… YouDescribe, behind… oh boy, I’m trying to remember the list. It’s very long. I’m sorry Josh, I’m not remembering off the top of my head. But lots of great stuff. 

You should ask him if you’re interested in blind tech. Many other things.

He’s going to talk us a little bit about Good Hackathons vs. Hackathons for Good. Can I hand it over to you, Josh?

[applause]

Can you guys see my slides? Sweet! Um, hi, everybody. So I’m Josh. Welcome to this amazing event. This University of Washington CREATE Hackathon. Thank you Jen, for setting this up. Thanks to all the organizers for making this an amazing opportunity for us to connect and grow and learn about accessibility.

Thanks a ton. This is super exciting.

Hackathons are one of my favorite things to do, so it’s really an honor to be here to hang out with you all and to be a part of your hacking and accessibility creation, learning, and growth here, which is exactly what I hoped we’re going to do.

So Jen mentioned that I’ve got lots of things about me. But the main thing that I’ll mention is I’m a blind designer of primarily what I do. I’m also a researcher. I tell people that I research accessible experiences. That’s primarily what I do. I’m a researcher. I tell people that I research accessible information.

So, being blind is… it doesn’t qualify me alone to do this work. I’ve been doing this work for decades and decades. I got my start developing screen readers in the early 90s developing Outspoken for the Mac. 

This is the very first screen reader for any system, so we developed, at that time, a number of really cool approaches to screen reading for graphical interfaces, which had not been in existence yet. 

And I went on to… from there I went on to my Ph.D. at UC Berkeley in psychoaccoustics. And I studied hearing and psychoaccoustics, which psychoaccoustics is basically how hearing works. And it’s because I wanted to use non-speech sounds as computer interface elements to present information. I’ve managed to do some of that.

But really what I managed do in my career is… learn how to listen and learn how to work with lots of different kinds of people, lots of different kinds of disabilities, and lots of different kinds of people with and without disabilities who don’t really know anything about accessibility and disability. Some of those things I’m going to talk about today in this presentation. 

I’ll also mention that I do have slides; I’m showing slides… you don’t have to look at them. They don’t matter. I will be saying everything that’s on my slides, or at least paraphrasing them. The slides are there for people who need to look at something. 

I usually… I often don’t use slides, and I feel like it works. But I think it helps people to focus attention to look at something, so I’m willing to do that accommodation for those who need it.

[audience chuckling]

The presentation I will be doing is largely lifted from my chapter in “Digital Accessibility Ethics: Disability Inclusion in All Things Tech” is the name of a book that was published earlier this year. The editors are Lainey Feingold, Reginé Gilbert, and Chancey Fleet. And I’m really honored to have a chapter in there, chapter 10, on hackathons and capstone projects and digital accessibility ramifications thereof.

So the talk that I’m giving today is really about that. It’s not really about the chapter. The chapter is about this. It’s about how to design hackathons that focus on disability and accessibility in an ethical, meaningful, and impactful way. I’ll just say it in a non-ableist way.

It’s really easy to for these hackathons to go off the rails. So let’s talk about why hackathons are cool. You are all here. You know hackathons are really cool. Say “me” or raise your hands if this is not your first hackathon.

[several audience members say “me”]

Okay, so we have some repeat offenders.

Is there anybody here for whom this is your first hackathon?

[several audience members say “me”]

And so this is this is going to be a really special… introduction to participating in a hackathon because this one is different. This hackathon, because of the way it’s been organized, because of the way it’s been setup is different.

But what is the point of a hackathon? We learn all kinds of stuff by… doing projects, collaborating, talking about stuff. It’s participatory learning. It’s hands-on learning. It’s an amazing way to build skills and knowledge and connections. You have the potential to actually create things that will have an impact on people… will potentially make a difference to even just a few people if you address a problem that needs addressing.

It gives you an opportunity, if you haven’t learned before about disability and accessibility and design, it offers an opportunity to connect with those areas. 

If you already do know about these things, if you’re an experienced person in this area, it gives you a chance to learn more and to teach.

And so these are amazing opportunities.

And of course, I didn’t write it on my slides.

I think one of the most important impacts of these hackathons is not the tools that you build, but the skills you learn and the connections that you make during the hackathon.

The things that you build… I hope it’s not de-motivating for me to say it… but that’s not the point. The point is building new skills, building knowledge about disability and accessibility, and meeting new people who you may be friends and collaborate with for years. That’s the really exciting part.

But there’s a lot of there’s a lot of potential for ridiculousness in accessibility hackathons, especially when we don’t have a clear understanding about what disability or accessibility requires. When you come to solve problems that you don’t really understand… you are likely to make serious mistakes.

I’ve got some headlines on the screen. One of them is something to the effect of “Students unlock independence with miraculous stair-climbing wheelchair.”

“New AI ASL interpreter built in 36 hours.”

“Braille printer built from Pringles can and Legos transforms literacy for the blind.”

These are ridiculous. Nobody’s building those projects. And yet, we see headlines for this.

I have a Google alert that sends me an email whenever “disability,” “accessibility,” “technology” — I’ve got a bunch more in there. You have to put in… if you use the term “blind” in there, you have to say “not windowshades.”

[laughter from audience]

Because otherwise you get lots of stuff about velour [louvre] and Venetian blinds…

But I get alerts all the time in my inbox that are, you know, these student groups, these engineering groups at universities that have solved, have transformed that will

transform disability. They’re going to change the way… unlock independence. They’re going to make blind people or people with other kinds of disabilities,… they’re going to circumvent all barriers. This hyperbolic language is really problematic.

And very often, these groups have solved problems that don’t need solving because they don’t understand what the problems are.

So the problem… what creates these headlines is the fact that non-disabled hacking teams or capstone teams… people who don’t have a connection to disability or accessibility already, don’t really understand the problems that they are addressing. And they often don’t even… they’re building their ideas about the problem from their ideas of

disability from history, literature, and popular culture, which are filled with ableist prejudice and assumptions about what disabled people need, what disabled people can do.

And so… basically… ableist assumptions are no substitutions for usability studies or market research. You have to understand what you’re actually trying to solve. You have to understand it from the perspective of the people who are going to use it.

So, also very often, there’s no disability or accessibility expertise or mentorship or input into the project when the project needs that input. Often they’ll come around at the end of the project to find some disabled people in their community to show them what they built and to get some sort of evaluative data.

It’s too late. You can’t fix it. You’ve already built something that embodies all of the assumptions and ableist attitudes that you came into the project with. So it’s just not going to work. You have to… well I’ll get to what you have to do in a second.

So, the other problem is that, when you don’t have disabled knowledge in the room, or accessibility knowledge in the room, while the project is being built, you will also don’t have disability and accessibility expertise in the evaluation. The professors doing the evaluation don’t have the skills they need.

And the press office definitely doesn’t have the disability knowledge that they need.

So you wind up with people who don’t know what they’re looking at and give all kinds of praise and feedback on projects that really shouldn’t be praised.

So the students walk away with this idea that they’ve done something great, and they think they’ve learned something really important, which they haven’t. They’ve learned exactly the opposite.

So, what’s the solution?

People with disabilities have to be involved in a hackathon project at every stage, at every level. They have to be involved in a hackathon at every stage, at every level.

If you don’t have that expertise, you will get somethings, if not everything, wrong. 

You have to have the organizers of the hackathon include people with disabilities and accessibility expertise. Because while you’re setting things up, you need to know…

Is where I’m putting the food accessible to everyone?

Is the way I’d doing nametags accessible to everyone?

Is the way we’re doing captions or ASL interpretation or other approaches… is that going to be accessible?

So, again, kudos to the CREATE team — a unique group of people who does have this kinds of expertise.

This is why this hackathon is going to be different from many others.

Also, you need accessibility and disability mentors in the room while you are doing your hacking. You need to be able to say, ‘hey we’re thinking of doing X, Y, and Z, what do you think?’ And those mentors can say, ‘well, that’s a great idea, but here are the gotchas that you need to think about in putting that together.’

The mentors are not to solve your problems for you; the mentors are there to point out the questions you need to be asking. And without that expertise, they won’t be able to guide you. We need disabled participants. We need participants with accessibility knowledge and expertise. And we need judges with accessibility knowledge and expertise, where judges are used. If you don’t have judges who know what they’re looking at, how are they to decide which projects are best.

Not all expertise is the same. I’ve been using ‘disability knowledge,’ ‘accessibility knowledge,’ and lived experience. These are three different types of expertise that I want to pull out for us.

I’ve got a Venn diagram on the screen. I’m not going to describe the diagram; I’m going to describe… what the Venn diagram is trying to communicate.

So there are three types of expertise that I want to draw your attention to that are critical for the success of an accessibility- or disability-related hackathon. And these are:

Lived Experience. By lived experience, I mean people are disabled themselves and disabled long enough to… understand where they are.

I have a caveat about… the “long enough” part, because very often when people become disabled, early on, I don’t consider them to be… to have lived experience. I consider them more to be non-disabled people who have acquired a disability. But they haven’t learned yet to think about the world from a disabled perspective. They’re more likely to be thinking about the world from a non-disabled perspective. You need a little time to let that mature. So lived experience requires a little time.

Lived experience gives you knowledge of your own disabled experience. You are an expert in what you experience as a disabled person. And that is not to be minimized, not to be… shrugged off. It is one of the most critical types of knowledge. But it is not the only type of knowledge and it is not sufficient to develop meaningful technologies. Because one person knows about one person’s experience… There are as many ways to be disabled as there are disabled people.

Disability Experts are a different type of expertise. These are people who have deep and/or broad knowledge of disability or community experience… and coming at it from a broader community-based perspective.

Very often people who work in disability… maybe you work at an organization that advocates for or connects with disability specifically… somebody who has built knowledge of a disabled community or disabled people in general through… work or study or something like that.

That’s what I would call disability expertise. It’s different from lived experience. You may or may not have lived experience and still be able to be an expert on disability. I don’t say that’s impossible. It’s easier when you have a disability. But I know many folks who do not identify as disabled who I do consider to be experts in disability.

And finally, we have the third category, which is Accessibility Experts.

Again, this doesn’t require that you be disabled; it doesn’t require even that you be a disability expert, but it does mean that you have deep or broad knowledge of accessible technology. 

For example, I have met many people who are experts in web accessibility who really don’t understand disability at all. But they are experts in web accessibility. I don’t want to minimize their expertise or the importance of knowing about having accessible interfaces, but the history of accessibility tools, like knowing what tools are out there, knowing what kinds of tools are used to solve what kinds of accessibility problems. 

That’s the kind of expertise that “accessibility expertise” represents.

So, my Venn diagram has these in three distinct circles that overlap with each other. 

There are areas where two adjacent circles overlap, where somebody might have two areas of expertise. 

And then there’s the central portion of the diagram where all three overlap. That’s… the sweet spot, the unicorn, the person who has knowledge of all of these areas — is an expert in disability, is an expert in accessibility, and has lived experience. 

But all three… the person who has lived experience. That’s amazing.

All three of these are important and you don’t need to be in that center sweet spot to contribute meaningfully.

Let’s talk about the halo effect.

The halo effect… you see this all the time, where people develop, you know, the stair-climbing wheelchair, or the dog shit-detecting bluetooth enabled shoes, where you have a team of sweet undergraduates who have done something amazing to help poor disabled people, and the professors are amazed, the PR office at the university gets involved. They put out press releases that are hyperbolic and abelist. And the students get all this feedback about how amazing they are and what they’ve done, but they don’t get any real knowledge of accessibility or disability.

These good intentions — there’s nothing wrong with being an undergrad who doesn’t know about accessibility or disability or lived experience who wants to contribute. This is an opportunity to learn. That’s what we’re here for; that’s what we do. 

But you need to have the right supports to do that learning and… good intentions themselves are totally insufficient to make meaningful contributions. 

And when you don’t have the right people around to give you feedback, you’ve got advisors and professors who are out of their depth of disability and accessibility, who… not only don’t they not know disability and accessibility, but because the students are doing something nice for poor, disabled people… the professors are like, ‘Okay, great! A+.’ Maybe it’s a little shaky on the research; maybe it’s a little shaky on the implementation, but you guys are doing something really important.

The people that are really underserved by this are the students. The students aren’t learning what we want them to learn. We have people graduating from universities who understand how to design with and for people with disabilities, whether they are, or are not, disabled themselves.

We want people to understand the importance of disability inclusion in designing for disability.

The halo effect and the sweetness and good intentions are not enough to teach you what you need to know when you graduate.

This kind of a hackathon, where we are today… this is a different situation. 

This is where you will learn things. CREATE is an environment where you do learn about disability, accessibility and disability lived experience, regardless of your own background. It’s an amazing place.

The harm is not hypothetical; it’s real. I mentioned… participants building inaccurate and ableist models of disability and helping…

And the other part is that not only does it erode trust with disabled communities, when you say ‘accessibility hackathon’ to disabled people, if they can. I just tell people that I’m rolling my eyes.

[audience laughs]

So the harm is societal. When you get these headlines out there in the world, it gives everyone the idea “problem solved; it’s all good.”

So we need to design these events with accessibility first. Accessibility must be… it’s not enough to hack on accessibility; we have to design and build disability and accessibility inclusion into every part of the event that we create.

So the event itself has to be accessible before anything else happens. We have to create an environment where people with disabilities are included, and also lead by example. Showing, demonstrating, and creating examples of how to creatively build accessibility into the rooms we’re in, the processes we’re in, the talks we give, etc.

This means that the announcements, the chat groups, the signups… everything needs to be thought about on the basis of accessibility. The physical spaces, the food, all of it. We have to just think about it. It’s not a courtesy. It’s fundamental. It’s not a thing we’re doing because we’re nice. It’s a thing we’re doing to be effective, to teach effective accessibility and design, in order to lead where we want people to go. We must be eating our own dog food and doing the things that we are asking others to do.

At the same time, accessibility is an ideal; it’s an asymptote; it inevitably falls short. I’ve never created any experiences or participated in anything that was accessible to everyone. It is a process, not a product. 

Accessibility is something that we strive for and we know we will fall short. But we commit to doing better next time. We do everything we can in order to make things as accessible and usable to everyone, but we also take notes. 

And we recognize that where we fall short, it’s a failure for the moment, not for the future, and we can do better next time.

And of course, who knows better what that accessibility looks like than people with disabilities. In order to create these accessible experiences, in order to build what we want people to participate in, we have to have people with disabilities involved at every stage, at every level, in every role.

So very often in hackathons, we have problem statements. Statements like, “Use AI to solve an information accessibility problem facing blind engineering students.” Or it might be “Use Arduino… and moisture sensors to build a… tool that helps… X, Y, or Z.”

So these problem statements… or prompts — I guess “prompts” has grown to have a different meaning these days. 

But prompts need to be meaningful. They need to be something that will actually connect with helping students and participants solve and think about meaningful problems. If you have an ableist problem statement, it guarantees an ableist outcome.

Problem statements have to be validated by people who really know, but the relevant experts. Asking students to solve a problem that has already been solved in five different ways isn’t doing anyone any favors… especially when you don’t point them to those existing solutions because you didn’t know about them as a the problem statement creator.

We need real problems with real context. And we need to include real users in developing those problem statements.

So obviously… I’ve mentioned this again and again and I’ll hammer on it once more.

We have to have people with disabilities as mentors and leaders. We have to have accessibility experts as mentors and leaders, and we have to have disability experts as mentors and leaders in any kind of hackathon. The realtime access to that type of expertise is the difference between learning something meaningful and recapitulating ableist stuff over and over again.

Mentors in the room can clarify disability use cases, explain not just the technology, but the context in which people with disabilities will be using it. 

What are the other tools where they’ll be using the thing you’re hacking on?

What are the other constraints that have to go into your set of requirements that you aren’t thinking of because you haven’t learned yet about disability in this context?

So, having the right expertise there to guide — and again, not to solve your problems for you, but to explain and guide the questions that you are asking yourselves, your team, and anybody who is co-designing with you. It avoids reinvention of inappropriate solutions and reinforces all of the right lessons.

When there is judging involved, you have to judge what actually matters. Rubrics must be designed in the context of meaningful disability-specific criteria. If you’ve got a rubric for your hackathon group, it needs to ask the right questions; it needs to be measuring the right outcomes. 

Judges obviously need real disability and accessibility expertise and lived experience, if at all possible. Otherwise, even if the rubric is good, they won’t be able to apply the rubric intelligently. 

You need the background to know how to evaluate the project, even if you have good on-paper guidance. Good intentions aren’t a scoring category. At least I don’t think so.

The best option for this kind of a situation is, don’t judge. Without judges, it helps people focus on the learning rather than the outcome. And that is really important.

I’ll return to that point in a second.

When the hackathon concludes, it’s important to report it. You have to work with your PR office to report the truth, not hyperbolic and over-the-top ableist headlines. 

You have to report the facts, not the hopes. 

You have to avoid the hero and savior narratives.

And you have to be transparent about who was and who was not involved. If there was a hackathon that was not inclusive of people with disabilities or didn’t have the right expertise in the room, you want to acknowledge that in any follow-ups, whether it’s a press report or just an evaluation of the event. It’s really important to track that stuff. 

Otherwise, it won’t change.

So, in figuring out what you want to hack on, and I think we’re going to talk a lot more about this in the course of the day… before you build, here are a set of questions to ask yourself and your team:

Is this based on a real accessibility problem facing real people?

Do we have advisors with the right expertise at every stage?

Did we research whether this is new or better than what exists?

Does the solution work in our user’s real world?

And if the answer to those questions is ‘yes’… if the answer to all of them is yes… then you’re probably on track. You’ve probably got a really good project going.

If the answer to any of them is ‘no,’ that doesn’t mean you have a bad project. It just means you need to think about how to change what you’re doing so the answer to that question is ‘yes.’

There is no magic solution to make sure your hackathon project is kick-ass and meaningful, but this is what you should be asking yourself and your team before you start.

And you should be striving at every opportunity to make the answers to these questions ‘yes.’

I’m almost done…

I want to say, once again, what you build is not the important outcome. Let’s build what matters. 

What we’re trying to build here is your knowledge of disability and accessibility. That’s probably the most precious thing that you will come away from this with. 

If you increase and expand your understanding of disability, your idea of how to ask the right accessibility questions in order to refine the solutions that you’re building, then that’s great. That’s a tool that will serve you forever.

Again, relationships with mentors and peers is another outcome that you want to build. Something that we’re building here this weekend, that will be invaluable in the long run, long after the thing you build today is obsolete.

Understanding people and problems before building technologies is core to everything. Ask the right questions, do the right research, connect to the right people BEFORE you build. Not just at the evaluation stage — you want to do it the entire time, really.

With that, I’ll say, let’s get started.

I want to say thank you. My website is mielelab.com. Once again, thank you.

[applause]

[Jen Mankoff, off mic while walking to the stage] … An inspiring and instructional speech — and I mean that about the content, not the disability identity. If anyone has questions, we can bring the microphone around.

[Miele speaking again] And please, when you ask a question, if you could say your name and kind of what role you have — if you’re a participant today or a volunteer, or a mentor, or some other role, tell us when you ask a questions please. And I want to also recognize there are some folks on Zoom who may be asking questions. I hope there’s a moderator who can forward those into the room.

[audience member speaking into mic] Hey Josh, it’s Bryce from Microsoft; I’m a mentor today. Wonderful content, I appreciate it. I really loved all the Venn diagram stuff because that really rings true with the WCAG bros.

I think that… I want everyone in here to really listen to what Josh says, because it’s true, but I also want to say, that as a person in industry and in tech, we try to make sure we move forward first.

So this is a lesson that I’ve had to learn, as someone who works with a lot of engineers, with a lot of good intentions, that sometimes you need to go down the the wrong path to get to a right path. I don’t mean to contradict Josh in anyway…

[Josh interjects] How dare you!

[Bryce again] I know, I’m the worst. But, no, it’s really cool, thanks Josh. That wasn’t a question, more of a comment.

[Josh speaks] I don’t think you’re contradicting me. There are many ways to learn, and one of the ways is by screwing it up. It’s not the best way to learn, especially when it has real-world consequences. When Microsoft or… insert big tech company here, gets something wrong and they put out a product that is… inaccessible or that they think is accessible but isn’t, or has other issues around accessibility, that… hopefully the engineers will learn.

But… they have to have the right feedback mechanisms in place in order to learn from their mistakes. Very often those mechanisms are either completely absent or broken. So that’s a really important thing, and, in the meantime, while that broken experience is out there in the world, not only are people with disabilities not being served by that technologies, but people without disability and accessibility knowledge, very often think that the problem is solved.

‘Hey, didn’t that giant tech company Z release a thing that does this? What’s wrong with you that you’re not benefitting from it. There are realworld harms by learning by screwing up, but it is one of the methods.

[Jen speaks] I love a good argument! Any other questions?

[Another audience member speaks into microphone] Hi my name is Twyla, I’m a participant. I was wondering what your thoughts are on… talking to people with lived experience with disabilities in the initial brainstorming phase… if you have an idea to “pitch” that or to ask more open-ended questions, such as “what needs do you see in your daily life?” Which is more effective, in your experience, in this fast brainstorming environment?

[Miele] Which one of the areas of expertise?

[Twyla] No, what type of questions do you think are most effective. More than open-ended, what is a need you see for people with any type of expertise, if I’m someone who I don’t think I have very much expertise with lived experience, with accessibility or with disability. Is it better to be open-ended or to have an idea and say, ‘hey, what feedback to you have for this?’

[Miele] It’s a great question. As a researcher, I have learned that people want to make you happy. People don’t want to hurt your feelings. People don’t want to imply that you’re stupid. They’ll often tell you what you want to hear. They’ll often tell you that what you’re show them or what proposing to them is a good idea… even when they don’t think it is.

I think that open-ended questions like, ‘what are some real problems in your daily life or in your work or in your school, what are some real problems that you have that you think might be solvable with technology? What are the top three things that you wish technology could help you with that it’s not helping you with.

Those are open-ended. But it’s framing it in, ‘what are the problems you have that you’d like solved?’ As opposed to saying, ‘I have a widget that I’ve been given and I’m going to create a technology with this widget… and how do you think this widget might be useful?

That’s what I call an engineering-driven solution, rather than a user-driven solution. When you start with the technology and go in the direction of the user, you’re going in the wrong direction. I recommend questions that don’t talk about the technologies that you want to use, keep those secret. If you have a technology you want to use, don’t tell the user about it… As them what problems they have, if they have ideas about how to solve them, things like that.

And again, while lived experience is really great, always remember when you are interviewing an individual with a disability, they are experts of their own experience, but they are not necessarily experts on the broader field of accessibility or even on other people with their same disability. They know about themselves; they are experts on themselves. You can trust that, for sure.

[Twyla] Thank you so much.

[Mankoff] One thing that I’ve found helpful when people with lived experience are not in the room, is that there is a lot of disabled creators these days and when you learn how to identify videos that are authentically talking about lived experience, as opposed to advertisements or other things that are not getting at the relevant content, there can be useful information in them. I was wondering if you have thoughts about the risks of looking to those spaces when you don’t have somebody in the room, and the benefit.

[Miele]I’m sorry, I need you to rephrase that; I didn’t understand.

[Mankoff] Yeah, there’s a lot of YouTube videos, Tiktok videos, and so on, created by disabled people talking about their frustrations with the technology or something in the world or something that works really well for them, based on their lived experience. Let’s say somebody in this room was trying to work in augmented communication, which I don’ t think we have anybody in the room with lived experience in that space, sometimes they can find videos that have people talking about that lived experience even if they can’t talk to somebody in person. And I was wondering if you have any thoughts about the risks of taking that approach as one of your data points, or where it can be helpful.

[Miele] I don’t think there’s anything wrong with taking those sorts of assets as one of your data points as your own data point. I think it’s dangerous if you take it as your only data point. Anytime you’re working with a dataset of one, you should be worried. If you have an idea that’s sparked by somebody with lived experience that you… from YouTube or TikTok or Instagram, or whatever… that’s great. That should be your jumping off point for your own inquiry into the needs there.

Don’t take that person’s statement as the entire set of requirements. It’s your job to figure out the design and requirements for the thing that you’re building. And in order to do that, you need many more voices than just one. Even if that person seems like an expert. If I sat down and told you how to build something… I mean, you should listen to me…

[audience chuckles]

… But, you wouldn’t be doing your job if you just listened to me. You would need to do a bunch of research, do a bunch of, at the very least, looking at discussion forums, looking for other people with the same lived experience, studying up what technologies already exists, verifying the person’s claim about a missing technology is really true.

A lot of the time, people don’t even know what’s out there and they go out complaining about stuff and it turns out actually that the thing they need already exists but was hard to discover for them, and sometimes for you. I love using online sources as inspiration, so to speak, but that’s a beginning point, not an end point.

[Kate Glazko, from audience speaks into microphone] Hi, this is Kate. I have a follow-up question for that… what if a technology already exists but it’s expensive or it’s closed source. Is open-source a good opportunity?

[Miele] I hate open-source.

[Everyone laughs]

[Miele] No, open source is amazing. As Jen mentioned I am the founder and board president of the Center for Accessibility and Open Source, also called CAOS…

[laughter]

[Miele] CAOS an organization that facilitates, supports groups who want to make their… advocates for more accessibility and open source in general, and supports the creation and sustainability of open-source assistive technologies — things like screen readers, Braille translators, eye-gaze trackers, augmentative communication tools, etc., anything that people with disabilities use specifically for their access needs is considered to be AT (or assistive technology).

So, when you’ve got a problem that you want to solve, it’s always good to know exactly what problem you’re solving. And that problem may not be a technical problem or that the technology doesn’t exist; the problem may be that the technology is too expensive. The problem may be that the technology doesn’t include all of the features that are needed. Solving the problems of expense, availability, discoverability — these are all totally legit ways to address problems, things that need fixing, and open source, I think, one of the most valuable and available ways to fix our accessibility, the problems that can be solved with technology.

[Audience member speaks into microphone] Hi Josh. I am Priya. In a fast-paced environment like a hackathon, where we have to solve a problem that is related to disability, with some lived experiences of the people who are attending… so how do we balance the solution in a way that solves the lived experiences, as well as is flexible enough for a diverse community… because disability is not a monolith?

[Miele] I didn’t understand everything you said? Do you want to try to rephrase it a little bit, just briefly so I can get the gist of it?

[Priya] Yeah, Here in this environment, we have a specific set of lived experiences of disability. So how do we design a solution to balance the specific lived experience of disability along with covering the broader aspect of it, so that it doesn’t become like the Bluetooth detector for dog… [chuckles]

[Miele] I think, coming up with a project that you’re both interested in, that feels fun and engaging and challenging to you as a team… that you also have enough data and expertise available to you that you can do something meaningful in that space. And remember that the most meaningful thing that you’re doing is learning.

So, if the only thing you do over the next days is study that problem and you don’t write a single line of code, I think that’s okay. There are no judges here. This is not a hackathon where we are evaluating you on your demos or your output. This is a hackathon where what you take away from it is the product and is the prize. And an opportunity to sit down and dive deet into a problem that you don’t understand for two days, is a gift. I hope that answers your question.

[Mankoff] Any more questions?

[logistical announcements]

[Miele] I’m going to be here the next two days. I’m wearing a… red dot, so I’m an advisor. Please feel free to grab me; don’t worry about interrupting me. Just come let me know you want to talk. I’m happy to engage with you on anything you want to discuss.

Thank you very much, Jen. Thank you everybody.

[Applause]