GABY DE JONGH: All right.
It is 11 o'clock, and shall we go ahead and get started,
Brianna?
BRIANNA BLASER: Oop.
I had to unmute myself.
One of those days.
Thanks for catching that, Gaby.
Thanks to everybody for joining us.
For those of you who I don't know, my name's Brianna Blaser.
I work with the DO-IT program at the University of Washington.
And so we're doing this webinar as part
of our ADEPT project, which is focused
on increasing the amount of accessibility
taught in engineering classes.
And I think part of the important thing,
too, is to make sure what you're making is accessible,
but also that when you're teaching,
you're doing it accessibly.
And so today, we have speaking to us Gaby de Jongh, who's
an IT accessibility specialist here at the UW
who I've seen give this sort of talk many times before,
and actually does it in an interesting manner, which
sometimes this is not the most exciting of topics
to many people, but critically important.
So I should also mention, if you're
interested in getting involved in ADEPT in other ways,
I'll put a little information about it in the chat,
and to keep an eye on your email afterwards for an evaluation
form.
That's part of the way we learn about how good of a job
we're doing, so I appreciate you taking the time
to fill that out.
So without further ado, I will turn it over to Gaby.
GABY DE JONGH: Great.
Thank you, Brianna.
Well, I'm actually going to start off this presentation
with a brief five-minute video.
You're going to see a video of my--
our colleague, rather.
Hadi works with both myself and Brianna
here at the University of Washington.
And he is blind and he uses assistive technology.
Specifically, he uses a screen reader in order
to interact with a computer.
And he does a really great job of explaining
what it's like for somebody who uses a screen
reader to interact with information
that is not accessible, and why accessibility is important.
So I'm going to go ahead and switch
gears for just a little bit.
[VIDEO PLAYBACK]
- My name is Hadi Rangin, and I'm
a member of IT accessibility team at the University
of Washington.
- Using a screen reader.
Hadi's an accessibility expert and he's also a user
of accessible technology.
He uses a professional Braille display and screen reading
software that reads everything on the screen.
- I am blind, and I use this a screen reader program at home,
and here, and everywhere.
A screen reader program is a software
that communicates with the operating system
and conveys the information to me.
- Welcome.
Blank.
An accessible page's design features--
- Even if you are reading as a sighted person,
you do not need every content at the same speed, right?
Sometimes, you have to make a pause
and then review what you have read,
and then digest the information.
For us, it's the same thing.
When we are reading, for example, a normal conversation,
we can read it very fast.
And then but when we are reading technical content,
then we go a little slower.
We make more pauses.
- Accessible University 1.
- I have slowed down my screen reader program.
- Banner.
Heading level one.
Graphic, Accessible University.
Banner end.
- But if it is, for example, about email, I can go--
- Faster, faster, faster, faster, faster.
- (RAPID SPEECH) Navigation region.
Show shortcuts button.
- I can go that fast.
- But it's not enough for Hadi to have a screen reader.
Websites must be designed accessibly in order
for the screen reader to provide a full experience of the web
page.
- I would like to show you two pages that are visually pretty
much consistent, identical.
But one of them is accessible, one of them is not accessible.
You will see in an inaccessible page
how difficult it is when those accessibility features are not
present.
- An accessible website.
- Accessible Universe.
- That is the accessible version of a fictional university
that we have developed here.
We call that Accessible University.
Here, for example, on this accessible Page,
I can ask my screen reader to show me the major component
of the page.
- Document Regions.
Dialog.
Regions.
Review.
- It tells me we have a banner section--
- Main menu navigation.
- We have a main menu section.
- Main.
- And the main body.
- Apply now form.
- And then there is another region.
- Content information.
- And content information, which is the same as footer section.
So assuming the page has been developed correctly,
I have a good idea about the major component of the page.
- An inaccessible website.
- Let me now go to see the inaccessible
version of this page.
- Home page.
Mozilla Firefox.
Accessible University demo site, inaccessible version.
Accessible University.
- This looks pretty much same as the other accessible version.
But here, when I ask my screen reader
to convey the major component--
- No regions were found on this.
- It said that no region found.
So for me, practically--
- Accessible.
Accessible university.
- --is that I have to read from top to bottom.
- Accessible university.
Alt tag.
Untitled.
No alt tag.
- And if those accessibility features are not present,
everything has the same weight.
So there is no way for us to say that where a major section
starts or where it ends.
It is really not just the facts, reading the content.
It is also about the navigation.
We have to discover the page, and then
that is the most time-consuming problem because once
you know where you are, what you are reading,
then it is usually fine.
But the discovery process or navigation process
is the most complicated process in the accessibility field.
In order to do it, I have to read from top to bottom,
whereas in the accessible version,
I could easily see what the major components were,
and then select the desired one, and move to that section
quickly.
- Menus.
Heading list.
Dialog.
Heading list.
- Headings is also a means to get information
about the structure of the content.
It gives me a good understanding,
good overview about the major or minor component of the content.
So I see that here.
- Welcome 2.
Featured story slideshow 2.
Accessible University 1.
- It said, Accessible University itself is a heading 1,
and under that, we have--
- Featured stories.
- Featured story, which is a heading 2.
It automatically conveys the information
that this section is a subsection of the heading
About.
You will see also that they'll overall
get an outline of the page and the major sections of that.
That is the difference between accessible and inaccessible.
[END PLAYBACK]
GABY DE JONGH: OK.
Hold on just a second here.
So I wanted to continue on with a little activity to kind
of drive home a little bit more about the difference, or about
the importance, rather, of adding structure, not only just
having text to speech ability, but also adding structure.
So I have an example of a course syllabus
for our fictional university, Accessible University.
And I have an audio recording of a screen reader reading
this information out loud.
And you can do one of two things.
You can either close your eyes and listen to the content,
or you can follow along as the information is being read out
loud.
SCREEN READER: Word.
Document 1.
Window.
Page 1 content.
Edit text insertion at beginning of text.
Introduction to physics.
Course syllabus.
Textbook.
Our sole text for this course will
be Introduction to Physics, Second Edition, authored
by the instructor.
Course objectives-- to offer students exposure
to basic principles of physics.
To provide students with rich, thought-provoking discussions
during lecture sessions.
To provide students with experiential learning
opportunities during laboratory sessions.
Class schedule.
Week.
Topic.
Reading assignment.
1.
Course Introduction.
Chapter 1.
2.
Inertia, equilibrium, kinematic.
Chapters 2, 3.
3.
Newton's Laws.
Vectors.
Momentum.
Energy.
Chapters 4, 7.
4.
Matter.
Elasticity.
Scaling.
Chapters 8, 10.
5.
Wave kinematics.
Sound.
Electricity.
Magnetism.
Induction.
Chapter 11, 15.
6.
Light.
Reflection and refraction.
Emission.
Chapters 15, 18.
7.
Review.
Final exam.
Grades-- misspelled grades--
will be assigned on a 10-point scale.
90 to 100 is an A. 80 to 89 is a B, et cetera.
Homework, exams, and projects will be weighted as follows.
Homework.
Exams.
Projects.
1.
2.
Final.
1.
2.
Final.
15%.
20%.
10%.
15%.
Percent sign misspelled.
Program [INAUDIBLE].
Misspelled.
New line.
GABY DE JONGH: OK, great.
So I've actually put up a verbatim transcript
of the audio that we just heard of the screen reader
reading that information.
And I just have some--
these are mostly rhetorical questions for you.
But I just would like to know, how many objectives are there
in this course?
Are you able to find that information
in the textual transcript that we were listening to?
What is the reading assignment for week 3?
And how much is the final project worth?
So this is an example where we do
have a certain level of accessibility,
where we do have text-to-speech, but there
is no structure in this document, which does not
allow someone like Hadi to jump between the different sections
that we were able to visually view in the previous slide that
had the syllabi on there.
So what we're going to talk about is,
how can you increase your accessibility
in a few simple steps?
But before that, I wanted to talk a little bit
about some misconceptions of accessibility.
Many people think, or many people just
have a basic lack of understanding
of what accessibility is.
How do you make something accessible?
How do you create something that is accessible?
And that's largely due, in part, because accessibility
can seem like an abstract concept,
and it's not really taught.
A lot of people don't really do onboarding for using the tools
that many universities actually provide to faculty, staff,
and students on how to create accessible materials.
We, at the University of Washington,
have actually had a really big push
about trying to get faculty, staff, and students on boarded
on using the products that are available to them
and create accessible content.
It's also a misconception that it's
somebody else's responsibility.
It requires maybe special skills or special tools
in order to make something accessible.
That's actually a big misconception.
A lot of the tools that are available to many universities
and institutions out there already
have the ability to create accessible information.
And finally, some folks think that accessibility
is kind of like a last minute final touch-up, something
that you do at the end in order to make something accessible.
But really, what is important is to consider accessibility
throughout the product development cycle.
And we'll talk about what things to look for as we move forward
in this presentation.
I'd like to talk a little bit about four principles
of accessibility, as this speaks more to the structure of why
this is important.
First of all, all forms of communication
require input into the brain via at least one sense
of the body--
either your eyes, or your ears.
And then you need to be able to input
that information into their brain
so that they can process it.
If the information can't get there, then it's inaccessible.
So consequently, the content of the information
needs to be presented in different ways.
So if you have somebody who is not
able to see text information, is there an equivalent for nontext
information?
So for example, images.
Somebody can't read the text, or there's
no text equivalent for that image,
how are you going to incorporate that?
Another example is people who cannot hear audio or see
a video have different alternatives, as well.
Operable is the next principle of accessibility.
Not everybody uses a standard keyboard and mouse
to access information.
Some folks use alternative devices that
accommodate their disabilities.
Mouse-dependent content can be inaccessible to a person who
can't use a standard mouse, due to tremors of the hand,
insufficient fine motor control, or even lack of hands
altogether.
So functionality needs to be made available from a keyboard
or from another adaptive device.
Operability also means that users can easily
navigate, find content, and determine
where they are within the content
that they're navigating around.
And also, you want to make sure that the content does not
create seizures.
The third principle is understandable.
Let's say that the content is perceivable and operable
by users of all kinds of abilities,
but it's understandable to none of them.
Does that make the content accessible?
No, of course it doesn't.
Understandability can be just as big
of a barrier to accessibility as any
of the more technical issues.
So you do want to make sure that text
is readable and understandable, that the content appears
and operates in predictable ways for those users,
and that they're helped to avoid and correct mistakes.
Lastly, the fourth principle is robust.
Not everybody uses the same technologies now,
nor will they in the future.
And people use all different kinds
of operating systems, different browsers, different versions
of browsers, so forth and so on.
And some people have advanced features enabled,
while others have those features turned off.
That content needs to be compatible with future
and current user tools.
So with that, it is possible within most management systems
to have a fully-accessible course,
and it's also possible within all management systems
to have a fully-inaccessible course.
So we're going to talk about just five simple things
that you can do to ensure, or at least increase,
the accessibility of your projects.
And we'll break down these five steps
in a little bit more detail here.
So step one is use headings.
This happens to be a screenshot of Canvas,
which is the learning management system that we use here
at the University of Washington.
And Canvas is actually an accessible learning management
system.
And the reason why I have this screenshot on here
is because with this, you're able to create headings
in a logical manner.
If you'll notice the red circle that
is circled around the dropdown menu,
the individual has the ability to associate
the text within this particular text box
here as either regular paragraph text,
or header one, header two, header three.
I'm sorry, not header one.
Header one is actually it's going to be
up here where it says Welcome.
Header one is always the top tier of navigability,
so that's what's going to be your very top function right
there.
And then everything else follows suit there.
So the reason why headings are so important
is because good heading structure
helps people without eyesight understand
how the document is organized.
Screen readers and Braille users can also jump between headings,
as Hadi mentioned in the video before,
which makes navigation more efficient than if there
were no headings.
Hadi talked about having to listen to a document
from beginning to end and not being able to navigate
within that document.
Those of us who don't have any visual disabilities,
we do something similar, as well.
We usually look over the document itself,
look at the title, maybe look at the different chapters,
look at the weight of the different heading levels,
maybe look at the table of contents or the index,
maybe review some of the images within that document itself
before we go in, and dive right in,
and start reading from the very beginning.
So those headings must be in a logical order.
You want to make sure that you're
starting with H1 for the title, and then
use H2, H3, and so forth so on in a logical manner.
Doing so preserves the tab order and allows
folks who do not use a conventional keyboard
to navigate within the document a lot easier.
And to accomplish this outside of a learning management
system, you can use the Styles pane in Microsoft Office.
I'll show you an example here later on
if we have some time of what the Styles pane looks
like in Microsoft Office.
But there are already predefined styles in there
where you can already choose heading levels,
and those will act as anchor points
within that document, which will allow the screen reader
users to move back and forth within that document.
So for example, if Hadi wanted to reread the section on What
is Grading, if that section had an accurate heading level
associated with it, Had could call up
a menu that has all the different heading levels
for that document and jump directly
to that specific place within the document.
The next step is a adding alternative text to images.
So this is, again, part of the four aspects of accessibility.
You want to make sure that you have text
elements for nontext formats.
So within Microsoft Word, you do have the ability
to add alternative text under the Picture Formatting tab.
And writing alternative text is a bit of an art and a science.
But essentially, the main takeaway
here is, if you're adding an image or a logo to a document,
there's probably a reason why.
And best practices for adding alt text
is, what is the key takeaway of that image?
And that's how you're going to describe your alternative text.
Now, there are cases where you may have bar charts, pie
charts, or flow charts, or some more high-level science
information.
And I do have a resource for that on how to accurately write
alternative text for such things as charts and graphs
so that the user can understand that information.
So just as kind of a review, alternative text
does equal equivalent communication.
It helps folks who can't see the screen understand
what's important in images and other visuals.
The alt text must provide contextual information
about the image, graph, or figure.
And this is actually a really important part.
Sometimes we include images in our documents for whatever
reason, maybe for decorative reasons, or just
to give your eyes a break when you're reading.
Those kinds of images must be marked as decorative
so that the screen reader will skip those images
and then the user can just go on and continue reading the text.
I've actually had many conversations
with screen reader users who wish that all images would
be marked as decorative because it is very, very
disruptive to their concentration
and the comprehension when those images do come into play when
they're reading long documents.
So it's kind of a judgment call there
to being judicial as to the number of images
that you're including in your projects.
Step three is adding captions to videos.
And if you'll notice, the video that I showed you
earlier with Hadi, that's an example of a captioned video.
And there are many reasons why we would
want to caption our video.
For example, Hadi is a nonnative American English speaker,
and so some folks may have difficulty understanding him.
So having the captions there would
benefit somebody who doesn't necessarily have a disability,
but benefits them in the sense they're still
able to perceive the information.
This is also true for individuals
who have hearing disabilities.
Captions are very helpful in that regard.
There is a difference between closed captions
and open captions.
Closed captions can be turned on and off by the user,
while open captions are kind of burned into the video itself.
So an example of open captions would
be if you're watching a movie and there happens
to be a foreign language component to that,
and that foreign language shows up
in English subtitles on the bottom, that
is an example of open captions.
Audio descriptions are additional audio information
in a video for individuals who have visual disabilities.
So audio descriptions give additional contextual
information to individuals who cannot see the audio,
but describe what is happening in that particular scene.
So depending upon your video, you
may want to consider adding audio descriptions for folks
who have visual disabilities as an added accessibility
accommodation.
And if you're not able to have a closed caption for your video,
you're also able to create a transcript.
Actually, YouTube makes it super easy to create
closed captions and a transcript automatically,
and it does so using speech recognition.
But you have to understand that that speech recognition is not
100%, so it's completely computer-generated.
So you do need to go back and review the transcript,
and make sure that the information is accurately
communicated or accurately transcribed.
This is particularly true for content
that is scientific in nature, has
medical jargon, or legal jargon, or scientific jargon.
So those are ways to increase the accessibility
of your videos.
Step four is to make sure that you're
uploading accessible content.
This is a screenshot of Canvas, which is, again, our learning
management system that we use at the University of Washington.
And last year, we acquired a plugin called Ally, which
is actually through Blackboard.
And what Ally does is it gives an accessibility
score of the documents that are uploaded to the learning
management system.
And you can kind of see that towards the right-hand side
of the screen there.
There's a form field there called Accessibility,
and there's different dials.
And those dials come in different colors.
You'll see a green one, there's a red one,
and then there's a yellow one.
Green means that the document is high accessibility, red means
the document is not accessible at all,
and yellow means that there is some accessibility features,
but it's not completely 100% accessible.
Within Canvas and Ally, if you click on these little dials,
especially on the red ones, it will walk you
through-- it will tell you that you
do have issues that preclude accessibility and asks you
if you want to fix them.
And it will actually walk you through,
step by step, of the process of how to fix those issues, which
is pretty cool, which is one of the reasons why we bought Ally.
And we can also pull reports for everybody
who's using this system to kind of look and see,
have they improved their accessibility scores
of the files that they have uploaded?
So it turns things into like a little game, or at least
to give some folks a motivation to increase the accessibility
of their documents.
And it seems to be working, so we're pretty happy about that.
But I wanted to include here that accessible content needs
to be created in a way that communicates structure
to assistive technology.
And examples of things that have good structure--
for example, a table of contents.
In Microsoft Word, there is a Table of Contents Builder which
creates links within your document
to certain chapters or subchapters,
and it's all completely accessible.
So Microsoft has done a lot within their software tool
to make sure that when you're creating documents,
using the methods that you already know
is going to create an accessible document.
Again, we're going to talk a little bit about headings,
making sure that you're using your heading levels correctly.
And also using your lists, ordered
lists versus unordered lists.
An ordered list is a list that has either 1, 2, 3, or A, B,
C. Unordered list uses bullets.
And those are highly accessible, as well,
and easy for screen readers users
to understand and identify.
I haven't really talked about tables,
but I know that tables are used quite a bit
in document creation and web creation.
You want to make sure that your table headers are identified
so that the table is announced accurately to the user.
In the exercise that we were listening to before,
it was just reading the information left to right
and wasn't really associating the table header information.
It really should have been announced
what chapter you're reading first, for which week,
from which book.
And you are able to do that, as long
as you can identify your table headers.
And I do have resources for how do you identify table headers,
so I'll make sure that you have those resources for you.
Again, making sure that you have alternative text for images.
And if you have content that is not English,
you want to make sure that you identify the language as
such within your document.
Screen reader users and assistive technology users
have the ability to install and download foreign language
dictionaries for their assistive technology
so it will announce in the language accurately.
For example, if you have a Spanish document--
so the default for Microsoft Word,
if you're using it in the United States,
is that it's going to code information
in that document as an English document.
But if you have some Spanish words in there,
the assistive technology is going
to announce the Spanish content in a very
bad, computer-generated English accent.
So if you have that downloaded-- that Spanish dictionary
onto your assistive technology, and it is coded correctly
within the document, it will actually announce it
accurately out loud.
Other things to consider.
We're talking mainly about HTML, Word, and PDF
as our authoring sources.
And each of these formats include
support for accessibility, but some formats
are better at supporting certain features.
For example, math content is very much supported in HTML
and somewhat supported in Word, but absolutely not supported
in PDF.
So for example, we have a project at the University
where we're remediating a bunch of documents for departments,
and I've been working with the calculus department.
And they have a bunch of old worksheets
that they would like their students to practice on.
However, they converted those to PDF,
and PDF just does not have the ability
to announce mathematical computations accurately,
whereas in HTML and Word, they do.
So those are some things to consider.
Also, when we're talking about PDF documents,
there's two ways to create PDF documents.
They're not necessarily created out of the blue.
Either you're scanning a chapter from a hardcopy book
and it creates a PDF document, or you've
created a source document and have either
exported that or saved that as a PDF document.
So in the latter example, if you're using a software package
in order to produce a PDF document,
does that authoring tool of the source document
allow you to create accessible content?
Well, Microsoft Word does have an accessibility checker,
which does allow the author to make
the document more accessible.
The second thing you need to consider
is, does the author know how to create the accessible content?
So the example for that would be,
are they using styles in Word?
Are they applying headings?
Are the headings created just by simply changing
the font size and the weight?
It's a lot easier to create an accessible source document
and export that to an accessible PDF document
than it is to fix the PDF document
and make that accessible.
That really does require a lot of skill.
And then the last step is just to ask questions
about the accessibility of certain features
before selecting those tools.
So for example, this is a screenshot
of a discussion board.
And at the very top here, I can see that Teryl Thompson has
posted the discussion, and then right
underneath that, I can see that Aaron Cannon has posted
a response to the discussion, and then underneath that,
I can see Dana Gray has posted a response to Aaron's response,
and then underneath that, I can see that Dana Gray has actually
posted a response to the original question.
And the reason why I can tell that is visually.
I can look here that Dana's first entry is actually
indented a little bit, and it seems
to be connected to Aaron's original post,
so it gives me a good visual indication
that these are responses to the post.
Now, is that information conveyed accurately and clearly
to screen reader users?
So those are things that you may want
to take into consideration.
This is a screenshot of, I believe,
an old Adobe conferencing source that may or may not
be used currently.
But I wanted to show this because there's
a lot going on here.
So you can see on the right-hand side,
you have your PowerPoint presentation.
Kind of in the middle here, you have your chat room,
and you've got some people discussing what's going on.
And then off to the left here, at the upper-right corner,
you have a head shot of the person giving the presentation,
and then you have a list of all the participants.
And then back on the right-hand side here,
below the PowerPoint presentation,
you have some ads and stuff.
This can be very visually distracting
for somebody who has learning disabilities or anxiety.
There's just a lot going on here.
So there's a couple of things that you may want
to take into consideration.
As the person who is giving a presentation,
do you have the ability to turn on and off some
of these sections to make it less busy?
Does the user have the ability to turn those sections
on and off?
So those are types of things that you
may want to take into consideration, as well.
And collaborative tools.
This is a screenshot of Google Docs.
At the University of Washington we use Google products a lot--
Google Drive, Google Docs, Google Sheets, Google Slides--
as they're great for collaboration.
And you do have the ability to assign alternative text
to images in Google Docs.
You also have the ability to assign heading levels
in Google Docs, so it is a great way
of creating accessible information.
However, within Google applications,
you also have the ability to export to Microsoft products.
There's a bit of an issue there, because Google does not
export from their product--
it does not map to an accessible product.
So if you're creating a Google Document
and you export that to PDF, there's
no way that you can create an accessible PDF from Google
Documents, unless you have a special plugin called Grackle.
That's a separate workshop altogether.
So the other problem with Google Documents
is that I mentioned earlier that you
do have the ability to export to Microsoft products.
When you create an accessible Google Doc
version using heading levels and assigning alt text,
Google Docs is still pretty much in its infancy,
and the developers haven't really
perfected that to the point where it will role map.
If you output that from a Google Doc to a Word document,
those markups will not be included,
just because Google Docs has not incorporated that
into their product yet.
So it's great when you're working
as a collaborative tool.
But when you have a finished product,
then you want to have somebody who's
going to be in charge of that finished product,
export that to a Microsoft Word document,
and then run the accessibility tools within Microsoft Word
in order to make sure that the final product is accessible.
So let's see.
So that is all I have for you.
I've got some resources here.
So this is a link to making your Word documents accessible.
So I'm going to go ahead and click on this.
It just opened up over here.
So this gives a little bit more information
from Microsoft about best practices
for making your Word documents accessible.
It's a lot about what we talked about in my presentation.
Let's see, making sure that you have accessible text format.
So it gives some really good information there.
Let's see what's here.
BRIANNA BLASER: I encourage folks, if you have questions,
you can type them into the chat so that Gaby can answer them.
GABY DE JONGH: Yeah.
And then I've also included a link here
for effective practices for description of science content.
And I'm going to go ahead and click on that.
And that just gives really great examples--
let's see here-- of how you can explain a bar chart.
So this gives an example of a bar chart, guidelines
for how to write the descriptions for a bar chart,
and then this is the example of how this bar
chart would be described.
So it gives some really good information about that.
So that's all I have.
And if you have any more questions for me,
you can feel free to email me at gabyd@uw.edu.
Sorry.
And in the meantime, you can go ahead and ask questions
in the chat, and I'll take a look at those, too.
Hold on.
BRIANNA BLASER: And I am working on getting
those links in the chat.
They'll be there momentarily.
GABY DE JONGH: OK.
And my computer just went to sleep.
That's really weird.
There we go.
OK.
So it looks like I have a question here from Abigail.
Is the Ally plugin automatically installed on Canvas,
or is this something that Canvas users
have to upload individually?
So it's actually an enterprise solution.
Ally plugin is an enterprise solution.
So we had to purchase Ally for our entire campus
in order to take advantage of it,
and it was deployed as a widespread solution
so that all of the courses have access to Ally.
And that's something that you want
to do at the institutional level.
BRIANNA BLASER: Thank you.
GABY DE JONGH: OK.
Oh, yes.
Avis says, will you please share the links in the chat?
OK, yeah.
It looks like Brianna, you're working on that.
BRIANNA BLASER: I am.
GABY DE JONGH: OK.
And Caitlin says, we use a third-party website
for some homework in a class I teach.
How can I determine if it is accessible to start?
Can a screen reader appropriately
communicate the content?
So that's a good question.
There's a lot to unpack there.
I'm going to start off with the first part.
How can you determine if it is accessible?
You probably need to have somebody from your IT
department or if you have Disability Services
or if you have an accessibility IT department
in your institution, you probably
want to ask them and see if they can help you out with that.
That does require a bit of skill in order
to determine whether or not that third-party is
accessible or not.
So there's a lot that goes into that.
And if you have more questions about that,
Caitlin, then you can email me directly
and we can talk about how would you go about that.
What department in your institution
would you need to interact with in order
to get the help that you need to determine whether or not
that website is accessible?
OK.
Looks Brianna's pasted a couple of links there.
Any other questions?
BRIANNA BLASER: I was just going to say that UW accessibility
page has tons of good resources on this that I send folks
to all the time.
So that link that I put into the chat for the captioning,
if you go through there, you can find other great resources
that Gaby and her colleagues put together.
GABY DE JONGH: And we always update them.
These tools are changing, and they're
getting better and better, which is great to hear.
So as they are increasing in their ability
to create accessible content, we do update the information
that Brianna has shared in the links page.
BRIANNA BLASER: Gaby, two questions.
One is, are you willing to share the slides?
GABY DE JONGH: Yeah, I'm happy to share those slides.
Should I send them to you and then you can share?
BRIANNA BLASER: Yeah.
If you send them to me via email,
I will email them to everybody with the evaluation.
GABY DE JONGH: OK, yeah.
Great.
Happy to do that.
BRIANNA BLASER: I also got a question
privately over the chat about, how would you
suggest working with faculty who are creating
homegrown educational tools?
What sorts of resources would you share with them?
GABY DE JONGH: Oh, wow.
That's a great one.
We're actually trying to dissuade a lot of our faculty
here at the University from using homegrown tools
because we can't address the accessibility
of those homegrown tools.
So in order to kind of approach that, I would ask the faculty--
let's see.
And this is a very pedagogical approach.
The information that they're trying to convey using these
third-party solutions--
have they done any research as to the accessibility
of those tools?
And they may or may not have.
At least it gets them thinking about that,
that they may need to think about if they're using tools
on their own, have they done the research
in making sure that these tools are usable
not just by individuals with disabilities,
but individuals who don't have disabilities?
Sometimes tools are just poorly designed,
or may not make sense to everybody.
So have those tools been thoroughly vetted?
Stuff like that.
BRIANNA BLASER: Great.
Thank you.
Well, not seeing any other questions,
join me in thanking Gaby for this presentation.
And I will follow up the email with all of you.
Thanks a lot.
GABY DE JONGH: Thank you.
BRIANNA BLASER: Bye-bye.