BRIANNA BLASER: OK.
It says it's broadcasting.
And you can see attendees popping on.
RICHARD LADNER: For those that have joined us,
we're going to start in a couple of minutes,
just waiting for people to join the webinar.
I'm Richard Ladner.
Brianna, how are we doing?
Are people still joining?
BRIANNA BLASER: Yeah.
I'm still seeing people hop on.
Maybe give it a few more seconds.
Looks like it's stabilized a bit, Richard.
It's 9:01 if you want to go ahead and get started.
RICHARD LADNER: Hello, everyone.
My name's Richard Ladner.
I'm from the University of Washington.
And this is the SIGCSE panel
that we were going to have in March and couldn't do it.
So because we have such a big panel,
we postponed it till the summer because we're all so busy
doing our physical distancing and teaching online and all
the things that we had to do.
So this was the panel called How and What
to Teach Accessibility.
So we called this a teaching accessibility webinar.
I want to remind people that this is recorded.
And so it will be available later
if you have to leave, for example.
Or you can tell people.
And that link will be on the AccessComputing web page.
I wanted to mention a couple of resources, one other resource
besides AccessComputing.
That's Teach Access.
So if you search on Google for Teach Access,
you'll find a great number of resources about teaching
accessibility, in addition to our own website,
AccessComputing.
We will take questions at the end after about 50 minutes,
maybe 45 minutes.
And so at the bottom of the screen,
there is a Question and Answer button
that you can push to ask the questions.
If you want to use the chat, probably we're
not going to use that for question and answer.
But if you want to send a private message to somebody,
go ahead.
I also wanted to mention that we will be doing an evaluation.
And that evaluation link will be sent to you in email
afterwards.
There will be some things in the chat
that Brianna will put in there.
Brianna Blaser is my assistant at AccessComputing.
And so she'll be helping out with this also with the timing.
There are captions.
So if you want the captions, you can
go down again to the bottom of the screen
and pull up the little menu and push the Caption button.
And that will give you captions.
So I think we're about ready to start.
So let's move on.
So we have five great people with us--
Amy Ko, Leah Findlater, Anat Caspi, Paula Gabbert,
and Daniel Krutz.
And these are the topics that they're going to cover.
And I decided to do a bunch of different ideas.
For example, Amy will talk about introducing accessibility
in a web design course, Leah about teaching accessibility
in a master's level course, Anat about accessibility
as a theme in a capstone design course,
and Paula as, sort of at the other end,
accessibility as a theme as an intro computer science course.
And finally, Daniel will talk about his tools
to improve understanding about the need for accessibility
in the first place.
And these tools will be available
as soon as your grant is over, I guess.
So why don't we start with Amy, associate professor
in the Information School at the University of Washington?
Go ahead, Amy.
AMY KO: All right.
Thanks a lot, Richard.
Next slide.
So for context here, I'm at the University of Washington
in the Information School.
And we have a required client-side web development
course that about 210 students a year take with us.
And really, the course covers a lot of things on client-side.
We want students to understand the architecture
of the internet.
We want them to understand HTML, CSS, JavaScript, and other web
standards that support interchange.
And we also want to make sure that students can construct
accessible, responsive, interactive, and valid
client-side applications.
So that's a lot to fit into one course.
And I think it's a big challenge to even just cover
those basic things, let alone things about accessibility.
So the big problem we faced was, how
do we integrate accessibility into this course
without having to take other things away in the class?
Next slide, please.
So what we observed first is that HTML really
is a necessary part of any client-side course.
But it's really boring to learn.
And it's boring to teach.
Most students don't know it.
But they find it really straightforward to learn,
in most cases, and really uninspiring.
It's really a learning a bunch of tags and attributes
and not really embracing any of the interesting things
about the web.
And so this makes it for a very underwhelming way
to start the class.
So we observed that and took that as the problem
that we tried to solve by integrating accessibility
into it.
Next slide, please.
All right.
So here's what we did.
We started off by giving students a chapter of a book
that we wrote on HTML.
And it covers accessibility, motivates accessibility,
explains it, and talks about the relationship
between accessibility and HTML on the internet.
Next slide, please.
And then what we do is really immediately
get them into the habit of testing and verifying
for accessibility.
So students have to set up an environment where they're
doing test-driven development that validates
their HTML against accessibility violations,
including things like missing alt tags and other more
sophisticated things that linters can check for.
So they're getting immediate feedback
here that the HTML that they're writing is missing things
and is broken.
And we're trying to normalize the idea
that accessibility defects are defects.
They're not optional things.
They're the things that make a web page actually broken.
Next slide, please.
Step three here is then once they've
set up that environment, we ask students
to write a personal home page with static HTML,
including tags and images.
And we provide a template that has some injected
accessibility defects just in case students
manage to write accessible HTML the first time around.
It turns out that they never do.
They always introduce defects of their own.
So we get a baseline set of defects
that we've guaranteed that they'll
see plus a set of defects that they introduce themselves.
And these are the basic requirements for their project.
They have to include a title and an author
and a top-level heading, an image, a paragraph,
a hyperlink, and a list-- so really, really basic kinds
of HTML features.
And it's astounding to us that even with this really basic set
of requirements that students often
introduce 5 to 10 accessibility defects that
will show up in the validation step
that they'll have to go fix.
Next slide, please.
So once they find those defects, students
are required then to use the screen reader built
into their operating system to verify and experience
that defect that was being warned.
So once they see that there is a problem,
they have to go and see why it's a problem
and observe for themselves why it
would be impossible to use the page unless they
fixed the site.
And so they go through and understand
how to use the screen reader, how
to test with the screen reader, and how
to verify that the warning generated by the linter
is actually a real problem.
And then they have to write down why it was a problem
and then write down the fix for it.
Next slide, please.
So when we talk to students about their experience
with this, one of the things they note
is that because it's the first assignment,
it really does normalize accessibility
as a core part of web standards, of developing good software,
of build processes, and of test-driven development.
They also say that when they're forced to experience those
defects from a perspective other than their own--
like they've never used a screen reader before--
they do recognize this more general principle
that they're not necessarily in the best position
to judge the severity of defects.
They realize when they see that the use of the screen reader--
they recognize that they can see what's
on the screen with their eyes, in most cases, unless they
aren't sighted.
And so they start recognizing that they're really
not in the best position to evaluate whether or not
things are good.
Students often report being surprised
at how difficult a simple markup language like HTML
can be to get right, especially when you set the bar
as including accessibility.
And a lot of our alumni graduate and report that even
just this single lesson, which only
lasts in the first week of that class,
empower them to advocate for better
accessibility verification practices
at their organization.
So they would often go to companies
and say things like, why aren't we verifying accessibility
in our build process?
And they would go and bring tools into those
build processes and start checking those things in
and including them in bug reports and bug triage
meetings.
That is it for me.
LEAH FINDLATER: OK.
Should I start, Richard?
AMY KO: Richard's muted.
LEAH FINDLATER: All right.
Well, hi.
I'm Leah Findlater.
I'm an associate professor in human-centered design
and engineering at the University of Washington.
And I'm going to be talking to you today
about a course that I've taught since 2016 at two
different schools.
It's an elective course on accessibility and inclusive
design aimed at students who were
enrolled in a professional master's program.
And the class tends to have about 25 to 40 students in it
each offering.
And I should also note that this course was originally
inspired by a course that Amy Hurst taught.
And I saw that Amy Hurst is in the participants list.
So thank you, Amy, for that inspiration.
So next slide, please.
The primary learning objectives of this course are to be able
to describe how factors such as ability and situation broadly
impact design needs, to be able to explain accessibility
guidelines and implement them at a basic level of competence,
to be able to critically characterize and compare design
paradigms related to accessibility--
so this is things like universal design, ability-based design,
inclusive design, and so on--
and to be able to create new technology
prototypes that address accessibility issues.
So this is different than what Amy was talking about
because the entire course over the quarter
focuses on accessibility and a little bit
on other aspects of inclusive design.
Next slide, please.
So the course is roughly split into individual assignments
in a group project.
And I'm going to come back to these in more detail.
But the individual assignments include a weekly observation
journal, two web accessibility assignments,
and a poster presentation on a topic of the student's choice.
And the group project is a quarter-long codesign effort
with a single participant whose needs are underserved
by typical UX design processes.
Next slide, please.
One back.
OK.
So the big question that I want to discuss today and one
that I've grappled with over the years with this course
is how to engage students meaningfully with disability
while limiting the burden on the disability community.
So next slide.
I want to discuss five strategies that I have used
and that I am actively using in my course.
So first of all, I encourage students
to consume existing content out there
that offers first-person perspectives, things
like books, tweets, and blogs by disabled scholars and activists
or even reports on experiences using a particular technology.
And I include some of these perspectives and other material
in in-class activities.
Secondly, students do weekly entries
in an observation journal, where they sketch and critique
a design that they've encountered that week in terms
of accessibility.
So they have to think about, who does this design work for
and why?
Who is excluded and why?
And how might it be improved?
And one of the goals of this assignment
is to build awareness and take home the habit of noticing
accessibility issues.
Third is a module on disability studies.
And I include this to offer a critical perspective
and some context for the accessibility work.
So here, I typically invite a guest speaker with a disability
studies background to visit.
We have a great disability studies program
at the University of Washington.
And students learn about a variety
of models of disability and critique
common design assumptions, including assumptions
that they may have had themselves
or that we've talked about earlier in the quarter.
For example, what's the motivation
behind designing assistive technologies that are
unobtrusive or look mainstream?
And why might we think of different approaches?
And then beyond the disability studies module,
I also bring in a set of guest speakers,
some of who talk about their own lived experience
with disability in addition to their expertise
in a specific area of accessibility research
or practice.
So these are often other members of the accessibility research
community at the University of Washington.
And then finally, there's the codesign project,
which I'll go into in some more detail here.
So next slide, please.
As I already said, teams recruit their own participant
for this project.
Typically, this is somebody that they know.
And there's a lot of flexibility here as long
as the participant is going to allow the team
to explore the theme of inclusive design somehow.
So this is actually not focused specifically on accessibility.
People can explore other aspects of inclusive design.
But most teams do choose to focus on accessibility
because that's what my focus is on for most of the quarter.
The participant that teams recruit
is involved in all steps of the project,
including a project declaration, first
of all, which includes a brief description of the participant
that they must approve of themselves.
And they can even help to write.
And then there's an initial design discussion
with the goal of identifying a design problem or opportunity.
Here, I strongly emphasize the importance of the team
identifying a problem or opportunity
with the participant rather than assuming
that they've picked an important problem themselves
and then only focusing on solutions
with that participant.
Because if they do that, which is--
there's a tendency for students to do that when they're new
to this area--
then they may end up focusing, of course,
on the wrong problem.
One thing is that before this session, where the team is
identifying a problem or opportunity
with the participant, the students
need to first write down some of their assumptions going
into the session with what they are thinking
some of the problems might be and why
and then reflect on those assumptions
afterward in their written report.
The team then plans out a codesign activity
based on the design problem and runs a second session
with the participant to map out specific design directions.
And then following that, they create a prototype
based on that session and then go back
for one quick round of feedback with the participant
at the very end of the quarter.
So in total, this project requires about two
and a half or three hours of time
from the participant over the whole quarter.
And then finally, this is totally optional.
But participants are also invited to the final project
presentations, if they wish.
And this year, probably because we had online project
presentations, we had higher than usual participation here
and six of the nine participants.
So we had nine project teams joined
for the final presentations, which was quite fun.
Next slide.
So I've covered several strategies
for having students engage meaningfully with disability.
And there are many others out there as well.
But I also want to touch briefly on a few other areas
that I'm continually trying to improve with this course.
So one of these is, because this course is not just about
accessibility but does include some other aspects
of inclusive design, how do we bring
in some of those other topics while still allowing
enough depth and accessibility?
And so I'm not sure what the best solution is to this.
Maybe it's just an accessibility-only course.
We'll have to see what happens.
But what I've done in the past is mostly
inviting guest speakers who have other areas of expertise
come in and share those and then also allowing
some flexibility in assignment topics,
like the poster that students choose
to present to their classmates, as well as the participant
and what they work on with that participant.
Secondly is the question of how to ensure that participant
involvement is sustainable.
So how are we ensuring that participants are properly
compensated for their time?
This quarter, for example, I provided participants
with a gift card using some flex funds that I had.
And I realize that's not possible for all instructors.
And it's also likely not a sustainable thing for us.
So this is something that we need to figure out.
And then thirdly, how do we make accessibility
happen in the real world?
So these are professional master's students.
And they ask often, well, how do we
get this to work in real organizations
with the kinds of constraints that come up there?
And so one way that I try to deal
with that to help answer these questions
is to bring in at least one industry speaker each quarter.
But that is an area that I'd like to improve on as well.
Next slide.
So on a final note--
next slide.
Yeah.
On a final note, one of the first points that I emphasize
and one that I close with in the quarter
is that this course is not about us designing for them.
And I think that this is important for two reasons.
So sometimes I hear new students using this language
at the beginning of the quarter.
And I explicitly push back on it.
So one reason is that it's important for the class
to feel like a welcoming place for deaf and disabled students,
whether or not they want to disclose
that they have a disability to me or to other students.
And I don't expect that students are
going to share their own experiences with the class.
But I greatly appreciate when they do so.
And then secondly, I think it's important
for nondisabled students to start
to have an expectation that their classes and their design
teams and their engineering teams
will have deaf and disabled team members as well
and that they will also seek to create those kinds of teams
in the future because we need to have these accessible
processes.
We have to have inclusive cultures in organizations
in order to achieve the most impactful accessible designs
in the end.
So thank you.
RICHARD LADNER: Thank you, Leah.
So next we have Anat Caspi.
ANAT CASPI: Hi.
Yeah.
As Richard said, my name is Anat Caspi.
I'm the director of the Taskar Center
for Accessible Technology at the Paul G. Allen School at UW.
And before I discuss the accessibility capstone--
and actually, it's great that I follow Leah
because a lot of the themes resonate in our course.
And though I didn't quite highlight the progression
of the projects that students follow,
they also follow this codesign principle,
which the Taskar Center in general follows.
And our focus is really on deployment and translation
of accessible technologies.
And so having this focus puts us in a very unique path
with its own demands.
And at the core of working on accessibility
is the understanding that, as engineers, we should always
be mindful of the extremely heterogeneous and diverse needs
and requirements that people present as users.
And in all of our projects, we work
with community members as codesigners
and also work in a very interdisciplinary way.
And so the bottom line is that we've cultivated communities
of practice that includes people of all abilities, ages,
caregivers, therapists, practitioners, all of whom
engage regularly with our students
throughout our projects.
And they're the ones who ideate on project ideas and needs.
And so typically, the accessibility capstone
follows the needs prescribed by these communities of practice.
Next slide, please.
So we have been very fortunate in the Paul G. Allen School
in that it's been one of--
UW in general has been one of the institutions that
have been at the forefront of accessibility research.
And our faculty and researchers have been seminal figures
in this field, which means that, for the most part,
we can very comfortably address accessibility
as an issue that's pervasive to usability, which I recognize
is not always a luxury in other institutions.
And so really, there's an understanding
that in all of engineering and design,
rather than having to address it as a specialty subfield,
this is an a core facet of engineering and design.
And so that's been very important to us
as we pursue an understanding among the students
not only that accessibility is important.
But it's deeply connected to the fact
that our built environment and our technology environments
have traditionally been built in a mismatched manner
to the majority of people.
And that's something that we continually
emphasize in the course.
And also, for inclusive design to be done appropriately
and ethically, we have to see the fault
in building mismatched products and environments.
And therefore we're not trying to fix or ameliorate
the deficiencies of any particular population,
but address this mismatch in design and engineering.
And broadly construed, this is the social model
of disability, which doesn't address people
as if they're coming from some kind of deficit.
But rather, we're trying to correct
design and engineering practices that in the past
have failed to take all bodies or abilities into account.
Next slide, please.
And so this is how the accessibility capstone
is construed as designing technology
for the entirety of the human experience.
And that is a skill that we find valuable regardless
of what path our students choose to take later on.
And so our accessibility capstone specifically
provides students exposure because the students
are required to interact with needs experts who
are users of accessibility features
and assistive technology in the local community,
along with therapists, coaches, and caregivers.
And those are also part of our community of practice
that engage with us on a typical basis.
And to Leah's point as well, we do
remunerate our needs experts who engage with our project teams.
And that's been something that was definitely something
that we had to work through with our school.
But I'm glad that we were able to address that.
And we do acknowledge that some institutions don't
have the ability to do that.
So our needs experts themselves tend to be professionals
in various fields.
Via assignments, students become tuned to the challenges,
being the design, economic, and social challenges,
that people face in the development and also the use
of accessible technologies.
And the focus is on building understanding
by building a connection with a person who
sees these challenges on an ongoing basis.
And then an additional underlying message
is that engineers and designers can be and are themselves users
of accessible technologies.
And so through this engagement, participation, and interaction,
the team-based project experience allows the teams--
and the assignment guides them through a rigorous engineering
design process to identify and tackle
these mismatches between built technologies
and their use by individuals of all abilities.
Next slide, please.
And so as you can imagine, it takes a lot of effort
to build the kinds of relationships and communities
that can support student teams in this learning process.
But we also want to ensure that our students are not just
dropped into this interaction but are properly tuned
to the sensitivities and their own attitudes
before they begin the process.
So there is a prequel which teaches them
how to engage with disability studies themes
and talk about disability in a way that's
respectful and sensitive and understands biases,
potentially.
Next slide.
And so the steps of our capstone course,
which is a 10-week course--
the student teams are asked to codesign and build
a system component or process.
that meets the needs expert's identified needs.
And they're guided through the process.
So first, they engage in codesign process
with a needs expert.
And they write a contract together.
Then lectures define introductory concepts
of disability studies and how they relate
to engineering practices.
They also identify principles of inclusive design
and how they can use codesign skills in order to benefit
diverse communities largely.
And then they conduct contextual inquiries
with their needs experts and also some other potentially
primary users to understand the problem,
develop a deeper understanding of the use cases.
Then they devise specific technology specifications
and development plans.
And we're very strict about tying the contextual inquiry
goals with these technology specifications
in order to show them how the engineering process can
be directly linked to these more qualitative inclusive design
activities.
And so finally, they iterate on the prototype once.
And they use both quantitative and qualitative methods
to assess usability outcomes and accessibility by primary user
populations.
And so finally, I wanted to share, with time allowed,
the final capstone for last year's
capstone, the video that was made by the computer science
department.
Or not.
RICHARD LADNER: Yeah.
Let me figure that out.
[INAUDIBLE]
ANAT CASPI: The idea was to allow the students to speak
in their own words.
RICHARD LADNER: We'll put that link in the chat.
Somehow it played earlier, but I couldn't play it right now.
ANAT CASPI: So just to sum it up,
really, it follows the progress of three different student
teams and how they engaged with their needs experts
and, finally, shows the effort to create something that
is sustainable beyond the end of their own project
by placing their technology out in instructables on GitHub.
And we really do emphasize documenting to the point
where another developer or a developer community
might be able to take up those efforts
and continue building on top of that.
And in some cases, we've actually
been able to fully take on those projects
and progress them to real translation to the community.
Thank you so much.
RICHARD LADNER: Sorry about that, Anat.
Well, your time was up.
OK, Paula?
You're on.
PAULA Gabbert: Thank you.
Yes.
I'm Paula Gabbert.
And I am professor of computer science at Furman University.
So I'm happy to be here today.
Go ahead to the next slide.
So I'm going to be talking about a course
that we teach at Furman.
And it's essentially a CS0 course
that introduces computing topics on a breadth-first level-- so
a breadth level rather than an introduction
through programming.
What we do at Furman, though, is we introduce these topics
through the lens of an application area.
And so some examples of these application areas-- this
is not an extensive list.
But we have one on social media, bioinformatics, gaming,
modeling.
And then the one that I do is on accessible technology.
So again, we cover the breadth of computer science
through the lens of these application areas.
The course serves both as the first course in the major--
so it is a required course for our computer science
majors and information technology majors.
But it also serves as a course for the nonmajors.
So it's a service course in that respect.
And our bachelor of arts students at Furman
can use this course to satisfy their general education
requirement for math and formal reasoning.
So what this results in is providing multiple perspectives
within our course in order to talk
about accessible technology.
And so it's really an advantage having
both populations in the course.
So the next slide--
so why introduce accessibility concepts early?
So this is coming way at the beginning of the curriculum.
And there's a couple of reasons for that.
First, it supports universal design principles.
So again, universal design says we should design and develop
accessible technology from the beginning.
It shouldn't be an add-on to the end.
And so we should think of our curriculum that way as well.
We ought to be designing our curriculum
with accessibility right from day one,
right from the very beginning in the intro course.
And what I've discovered is that accessibility concepts really
intersect nicely with these core concepts, core CS concepts.
And so it really has lend itself well
to what we do at Furman, where we
want to introduce core concepts by applying them
to a particular area.
And accessibility concepts really lend themselves well.
And I'll illustrate that in just a minute.
But it also provides a broader context
for more specific accessibility training
in upper-level courses.
And so what I mean by that is it allows
us to talk about the social historical legal landscapes
that will motivate the need for appropriate application
development that will come later in the curriculum.
And so it really is a way for us to explore accessibility
early in the curriculum in order to motivate the need for doing
so later in the curriculum.
So on the next slide, there are some primary objectives
for the course.
We want to, again, motivate the need
for universal design principles by understanding
the legal, political, and financial issues
surrounding accessibility technology.
I do this in a variety of ways.
In fact, some of the things that Leah talked about in terms
of engaging students in discussions with accessibility,
whether I do that through having them journal--
I also do that by having people come to the class.
And I have our Office of Accessibility resources
director come and visit the class
and give a perspective for the local perspective of accessible
issues.
I've also been really fortunate to have
a Furman student who is blind.
And she has come to visit my class as well.
And she heard about the class and was
willing to come and visit.
And those days are actually the highlights
of the term, where she comes in.
And she's very open about her experiences
through the use of technology.
We also take a more national-level perspective
by looking at the Section 504, the Rehabilitation
Act, the Americans with Disability Act.
So we look at the national level.
And then we look at the global level.
I have them look at the United Nations Convention
on the Rights of Persons with Disabilities
and the World Health Organization, WHO,
report so that they can really get a sense of the issues
across the broad spectrum of the entire culture.
The discussions that result from that
are really formulated through some readings
that we do from a book that's edited by Lazar and Stein.
It's called Disability, Human Rights,
and Information Technology.
And we focus on these questions in our discussions.
How can we provide access to digital information
to all people at the same time and at the same cost?
Who should pay for the cost of developing accessible
technology and information?
How does technology aid people with disability?
And how does technology exclude people with disability?
And so we have classroom discussions
centering on these big questions and these big issues.
And then, of course, we also want
to be sure we cover our core computer science topics.
And then through these conversations
and through these discussions, the students
develop empathy for people with disability
and really see the need and are motivated
to learn about how we can make technology accessible.
So the next slide, we can see just an example
of some core computer science topics.
This is not a complete, exhaustive list, obviously.
So all of our courses, all of our sections
cover data storage.
But when I'm looking at data storage
and how data is represented digitally
through the lens of accessibility,
we talk about how accessible information is created
by translating from one type of data
to another using OCR or speech-to-text or
text-to-speech technologies.
All of our courses cover operating systems.
And again, through the lens of accessible technology,
we explore operating systems by looking
at the accessibility options on the Mac OS
because that is the platform that we have in our labs.
And so we look at the dictation tools, the VoiceOver, Zoom,
and alert settings.
All of our sections will cover programming and algorithm
development, at least two to three weeks of programming,
although some do more.
I use about two to three weeks of the course
to cover programming.
And I illustrate programming techniques
by using some really simple speech-to-text
and text-to-speech libraries that
are available through Python.
And so they can do some simple programming activities while,
again, exploring accessibility development.
Another core topic that we all cover is software development.
And so we discuss agile methods and the importance
of advocating for user involvement.
I have them watch Haben Girma's presentation to the Apple
Developers Conference.
And that is really a good eye-opening type of activity
for them to do.
There are other topics that we cover.
And obviously, there are also topics that are optionally
covered, like artificial intelligence and databases,
that we can cover if we want to.
But they all lend themselves to examples
within accessible technology.
On the next slide, at the end of the course,
I have the students reflect on what they've learned
and apply it to their particular discipline.
So again, I have a cross-section of the university.
So we start with the social definition of disability,
which Anat mentioned, which argues
that a person with disability is impaired
not by their own impairment, by society's inability to provide
appropriate resources.
And then I ask them to reflect on their major, potential
major, or main interest area and how
the topics we've discussed for accessibility and accessible
technology can be incorporated by that discipline
to benefit society.
How can your discipline contribute positively
to minimize social impacts of disability
and include all persons in the activities, information
access, and communications within your discipline?
So on the next slide, there are a couple of quotes.
I have others.
But these are just some examples of what students are
saying in these reflections.
So an English major said, as a reader and writer,
I know how important it is to include
all voices in the literary world, particularly
those voices that have been historically unheard.
By fighting for more accessible ebooks, keyboards,
and other technological aids, my field
can benefit from hundreds of untold stories.
And then a politics and international affairs major
said, we've created a system of information
to keep the people informed of what is happening
in the political field.
That system does not include those
with visual or social disabilities.
Girma pointed out in her presentation
at the Apple Conference that we just
assume things of people with disabilities.
We assume that a blind woman won't use a camera because it
hasn't been made accessible to her, which is one of the things
that Girma talks about in her presentation.
This student applied that to his area to say,
we assume a man with a social disability
won't be informed and active in politics because it hasn't
been made accessible for him.
And there are other illustrations
of how students are reflecting on this concept
of universal design and applying it
to their particular discipline.
Another politics major mentioned that getting people
with disability involved in political process
will help make our democracy stronger.
So again, these examples are illustrating how we can really
motivate students to think about these issues
at the beginning of their curriculum
and help get them motivated to ensure that they are
ready for those upper-level concepts
and upper-level courses if they are pursuing their major.
But in addition, we are also serving our nonmajors
because all of the students at Furman
will eventually be creating digital information
and promoting and utilizing or advocating
for the use of technology within their various disciplines.
And so by understanding the need for accessible technology
by all the disciplines, it becomes a really powerful tool
for us to impact not just computer science majors,
but other majors as well.
So the future challenges for us are
to really try to get at how we can do this
throughout the curriculum and make sure that we introduce
those concepts early in the term, early in the curriculum
and not wait till the end of the curriculum as an add-on.
So that is all I have.
Thank you.
RICHARD LADNER: Thank you, Paula.
And Daniel, go right ahead.
DANIEL KRUTZ: Hey.
Thanks, Richard.
And first, thanks to Richard for organizing all of this.
So I'm Dan Krutz.
I'm an assistant professor at the Rochester Institute
of Technology.
I'll be the first to say, by background,
I'm not an accessibility expert by any means.
I am a software engineering expert.
And when I started thinking about a couple of years
ago was how to actually make it so folks who aren't necessarily
accessibility experts--
how they can include appropriate educational material
in their courses, in their curriculum,
especially a lot of institutions that might not
have the resources to have an entire major or even a course
focused on accessibility.
And so one of my objectives behind a project I'm working on
is how to make it so folks without the resources,
without the background can at least include
some material regarding accessibility
into their curriculum.
So I'll start off by saying anybody
who has created software knows that creating software
is not easy.
It's really hard to create software that's on time,
on budget, high quality.
And there's many important criteria
that we need to consider when developing software.
So things like security, extensibility, testability--
all of these things are incredibly important.
But one of the things that's not frequently spoke about
is how accessibility is equally important in creating software.
So it is something that we all know needs to be covered.
So how do we cover that?
Next slide, please.
So accessibility, as we all know,
should be at the forefront of the developer's mindset.
And how do we demonstrate this to students?
How do we make students aware that creating accessible
software is not something they need to do to check a box,
or they do it because they have to?
How do we get them excited about it?
How do we actually make them aware
that it really is important?
So next slide.
So the first thing you can do is you can tell students
that it's important.
And if you're anything like me, students
hinge on your every word.
They're on their edge of their seat in their classes.
They're incredibly excited all the time.
But for some folks, that might not work.
So another option is to actually demonstrate the need
to create accessible software.
And there's a couple of ways to do that.
One way I've been focusing on in some of my tools
is creating empathy.
So next slide, please.
So first I'll say, truly experiencing a disability is
quite impossible.
You cannot emulate what a person who is deaf or colorblind would
actually experience.
So our objective is to get it as reasonably close as possible
and do a reasonably good job demonstrating it to the user.
So one example of empathy-creating material
in our tools would be to demonstrate that experience
to the user as reasonably close as possible.
So what we might do to demonstrate
what a user with maybe a form of blindness
might experience the page would be--
is we would first ask the student
to interact with a web page.
And we'd show them a basic web page, as is shown on the left.
Then we would turn on an accessibility emulation feature
that would make the page appear reasonably as it would
to somebody who was blind or had a certain form of blindness.
And as you can see from the right,
that page is very blurry.
It'd be really hard to interact with.
And so by doing this, we're demonstrating
how it is difficult for a user with accessibility needs
to interact with a web page or, really, any piece of software
when it's not created in an accessible fashion.
So next page.
So one of the recent publications
we had at ICSE-SEET was we found that creating empathy
for users with accessibility challenges
is really important for accessibility education.
So we found that students pay more attention
to the educational components of the activity
when we create some empathy with them.
Students see the need for creating accessible software
as being much more important.
And at the end of the day, students
are more interested in the topic of accessibility.
Next slide, please.
So the question is how to actually create empathy.
And one of the things we are working around--
and I'll credit Richard with this statement--
is, how do you create empathy and not pity for the user?
And that's not something that's trivial to determine.
Some of the ways we create empathy in our activities
is we have testimonials from real people about how
inaccessible software has impacted them.
So one example we have is a student who is colorblind.
And they talk about how they've tried
to use software that is inaccessible to users
who are colorblind and how frustrating it is.
We do the same thing with deaf students,
where they might talk about how software that's not created
in an accessible fashion to them has adversely
impacted their experience.
And then like I demonstrated a minute ago,
we have tools that do a reasonably close job
to emulating existing software to appear as it would
to somebody who may have an accessibility challenge.
So next slide.
So next slide, one more.
So one of the sets of tools that we've been creating
are the Accessibility Learning Labs.
So the objective behind these tools
is to make it as easy as possible for instructors
to include an accessibility component in their curriculum.
And these tools are designed for courses ranging
from CS1-level classes and even high school courses all the way
to a graduate class, maybe, on web design or UI
design or, heck, even a project management class.
These are designed to make the participant
aware of some foundational best practices for creating
accessible software.
But most importantly in my mind, it's
to have the participant walk away from the activity saying,
accessibility is important.
I need to make sure that I'm focusing
on that in what I'm creating.
It could be the project manager understanding
that when a developer says, hey, we
need to spend these extra time and resources making sure it's
accessible, the project manager says, yes,
I understand why it's needed.
Let's devote those resources to it.
Or it could be the student understanding programming
for the first time, knowing that this is something
that should be baked into the software development project
right from the get-go, like I believe Paula mentioned.
And so all these materials are publicly
available on our project website at all.rit.edu.
I'll be the first to mention that I
think we have one or two labs that
are publicly available now.
But we are working on more labs that will be easily adoptable.
So next slide, please.
So some of the topics that we're focusing on early on
are vision-related accessibility challenges,
like color blindness, hearing.
We have a very large population of deaf hard-of-hearing
students at RIT because we are home to the National Technical
Institute for the Deaf--
some other vision issues as far as blindness, dexterity,
and cognitive challenges for participants.
So next slide, please.
And so this material is becoming available on our project
website at all.rit.edu.
We are looking for collaborators and adopters for this material.
It is entirely web-based.
So everything from the lecture slides to the YouTube videos
to the actual activities--
you only need a web browser.
And I think some of us may be doing some online teaching
over the summer and over the fall.
So obviously, this is something that folks can definitely
benefit from.
Even if you don't know much about maybe
a certain accessibility topic, like colorblindness,
these materials are designed so that you can easily incorporate
these into your classroom.
And then we are providing everything
that you would need to provide to your students
to conduct these activities.
So like I said, we are looking for adopters and collaborators.
And the nice thing is, early on, we can build to suit.
So if there are certain things that you'd like to see,
there's a good chance we can actually
build that into the activities.
All right.
So thank you, Richard.
RICHARD LADNER: Great.
Thank you, all of you.
That was a fantastic sequence of different approaches
to teaching accessibility.
And I'm going to ask Brianna to come back on.
Are you there?
BRIANNA BLASER: Yep.
I'm here.
RICHARD LADNER: Have you been following the questions
so that we can cover some of those?
We have about 10 minutes.
BRIANNA BLASER: Yeah.
So some folks have entered some questions into the--
if you use the Q&A tool.
And there are some that folks have answered in there.
And we can elaborate on those in a minute.
But there's one for the panel to address as a whole
that I think would be a great question to hear
what you folks have to say.
Robert Domanski asks, hi.
I'm curious to know if any of the panelists
have been able to gain adoption of these practices
from their departmental colleagues.
And if so, what strategies were most
effective in persuading them?
RICHARD LADNER: Would anybody like to start with that?
Anat or Leah?
AMY KO: If not, I can start.
RICHARD LADNER: OK.
Go ahead, Amy.
AMY KO: Sure.
The answer is a yes and a no.
So the no is I haven't been able to convince
any of my colleagues at my rank or above to change anything.
And this includes colleagues that actually are accessibility
experts, such as my colleague Jake [? Wolbrock, ?] who
I'm going to call out for not ever teaching an accessibility
course in the Information School because he keeps [? buying ?]
[? out of ?] courses instead.
We're busy, right?
It's a hard thing to convince busy colleagues
to do new things and to change the way that they teach.
The only success that I've had is
changing the behavior of colleagues
that are below me in rank.
So I happen to be the program chair
for our undergraduate program.
And so I essentially told all of our teaching track faculty,
we're going to do this.
And they did it.
And it wasn't so much an authoritarian move.
It was much more like, let me explain
to you why this is important.
Let's brainstorm together about ways
of implementing this in a way that's sustainable and usable
and built into our infrastructure
so we don't lose it.
So it was just a project that we did together.
But that was the effective strategy in my case--
was just using my power.
[INTERPOSING VOICES]
DANIEL KRUTZ: So I kind of flipped that, Amy.
And I'll say, I'm a third-year tenure track person.
So I have no power at all.
So I was able to implement some of my material
into our CS2 curriculum, which has
like 350 students a semester, I would say.
And we do have a department that is very focused
on accessibility.
And so I would say that's fortunate for us.
The way I was able to do it was, frankly, I said,
here's how easy it is to include it in your curriculum.
And you don't need to do anything.
And so everybody's super busy in their classes, especially
the average CS1, CS2 course.
So how can we make it as easy as possible for an adopter
and have an activity that maybe somebody can
do in 20 to 30 minutes--
so something that doesn't take a lot of time or resources
by the adopter?
So I think a lot of times, we need to flip it
and actually say, here's what we can do for you, not--
I don't know if this is the right way to put it--
what can you do for us, type of thing, like in the sense of,
include accessibility to do it because you have to.
But hey, here's what's in it for you, type of thing.
So yeah, Amy and I-- we're on polar opposites, I think.
I'm on the other end of the spectrum.
AMY KO: I had really different strategies when
I was an assistant professor.
You're totally right.
BRIANNA BLASER: Great.
There were also some questions-- does anybody else
want to address that?
LEAH FINDLATER: I was just going to say
that I'm lucky to be in a department that's
really supportive of including accessibility
content in things.
And I got to teach this whole course.
And since I introduced this course in my department,
we had another [? lecture ?] introduced,
an undergraduate fewer-credit-hour course
that includes a bunch of accessibility content.
And I'm hoping to introduce a course that's
five credit hours for undergraduates as well.
So that's my next challenge.
And then after that is making these courses part
of the required components of the degree programs.
PAULA Gabbert: Yeah.
And I was just going to add that curriculum redevelopment
and restructuring is always an opportunity
to introduce these ideas.
And as computer scientists, we're
constantly looking at curriculum because our discipline
is so dynamic.
So I think that just having those conversations
on a regular basis provides you that opportunity
to explore these ideas.
And you can be that voice, I would
hope at no matter what rank you are, just
in terms of introducing that idea in those conversations.
RICHARD LADNER: Anything else there?
A couple of questions--
Brianna, do we have a chat window where
we can put the links, for example, to the video?
BRIANNA BLASER: Yeah.
I have answered some of them in the Q&A.
And I think that I will put that in the chat as well.
RICHARD LADNER: Yeah.
Thanks.
Somebody asked for that.
One question that came up is for both Leah and Anat.
How big are your teams for your projects?
ANAT CASPI: I can address that.
I used to be of the mind that anywhere between two and four
is a good number.
But I've recently settled on three, especially
for our most recent offering, which was entirely virtual.
And I found that it would be really difficult to take
on the kinds of projects in just a two-person team--
the kinds of projects that we intend for them to take.
But at the same time, a group of four
was just too decentralized and hard to manage.
So we have generally preferred teams of three.
And I'll let Leah respond.
LEAH FINDLATER: Right.
OK, thanks.
I say max four.
And we've had teams from two to four.
I'd say part of that is that part of the reason why
I go for four as opposed to two or three,
which I think would be good for making sure that everyone is
really involved in the project, is
partly because I'm trying to offset this burden
on the participants.
And if we have teams of three or four,
then we don't have to recruit as many participants in any given
quarter.
And it still gives all of the students
a reasonable amount of exposure and effort level.
So it's trade-offs.
RICHARD LADNER: Yeah.
Thank you.
It was mentioned on the question and answer-- somebody actually
gave an answer that the W3C does have
curriculum for accessibility on their website.
So that's another place to look as well.
And I believe there are links to those from the Teach Access
website and from AccessComputing as well.
Somebody mentioned the real-time captions.
People might not realize this was not automatic captioning.
It wasn't speech recognition.
But we actually had a human at the other end.
And I'm sure everybody thanks that
human for doing such a great job with the captioning.
Anat, thank you.
You mentioned the contract that you had with students
in the capstone course.
Do you have any examples or pointers
that you might be willing to share with others about the--
ANAT CASPI: Yeah.
So I'm perfectly happy to share.
I never actually thought of that as something
that we ought to share widely.
But it certainly could be while redacting the names and things.
I think teams have come up with very appropriate ways
of addressing some of the questions
that Leah had pointed to in terms of,
how do we get needs experts to engage with our teams
while at the same time not burdening them and achieving
that understanding of, how often will we communicate?
What level of communication?
What are the expectations from different team members?
All of those things are asked of students and their team
codesigners to spell out in the beginning
of the course in order for them to have
that conversation, basically.
The contract itself is probably never read after it's signed.
But just having that discourse about, what are the terms,
is the important point in that assignment.
RICHARD LADNER: Somebody asked, do you
have suggestions on how to teach accessibility
in informal contexts as opposed to the classroom?
And I know, Anat, you're involved with that quite a bit.
ANAT CASPI: I think one of the forms
is just through advocacy, much like Amy had discussed.
Taking on the accessibility lenses
can become a part of life.
And it's all about how often and to what degree
you can strategically work within the community
in order to promote that accessibility lens.
And so in the past, with Richard, for example,
we've done informal workshops on accessibility lens taking
to AI and things like that.
So that's a semi-formal, I guess,
because it is an organized event but doesn't take part
in a course format or anything like that.
But I think largely, the kinds of activities
that we have engaged in are actually
going into the community and serving
on community panels and other areas
where accessibility might be seen as a marginal element,
let's say pedestrian and bike access committees, things
like that, where you can promote the needs of people
who require accessibility features in the environment.
But at the same time, that's not a formal conversation
or a legal process per se.
That's been my take on it.
But I'm happy to hear others.
BRIANNA BLASER: I was going to say, at UW,
there's a student group called HuskyADAPT
that I know you've been involved with,
Anat, too that does things like toy hacking
and that kind of stuff.
And I'm going to drop a link to a webinar
where we had some folks from HuskyADAPT
join us and talk about that.
RICHARD LADNER: Yeah.
I would like to say that our time is up.
And we're going to stop the recording right now.