- But I do think you made another very significant point.
- Which is empathy. Right?
- Unless you have empathy
and unless you really raise the awareness
of what it really means for users
people are going to not get it.
So I totally agree with that.
- Yah. I'd like to talk about that point.
At HHS, we have a employee resource group
of employees with disabilities.
And I've been talking with the person who supports
that group about creating an informal network
to bring together employees with disabilities
and developers of IT of all kinds
to do activities together
that people will be organized as we go.
And we're due for developers
to see how people use technology in real life.
But to also get to know people,
it will have social aspect but it will be informal.
Because creating something formally
within the government is
(laughter)
a nightmare and usually has things that come with it
that you don't want.
We hope that it's something that we will start small
and hope that it will grow.
But a lot of people are interested and we'll start meeting
within a year and getting it off the ground.
- From a vendor perspective I want to address that
cause I think that goes back to process.
Right?
How are companies engaging with the disability community
as part of the way that they design, they develop,
and they task their product.
So I think that's another question
that goes back to procurement.
So what's your process for basically being able to say to me
"This is the conformance statement." Right?
And asking those questions:
"Do you engage the disability user community?"
"Can I find those conformance statements,
whenever I need them?"
I don't want to ask you for it.
They should be posted all of the time.
Because that proves that then you are interacting
with a company that not only putting accessibility
at the heart of what they're doing
but they're willing to come out and give it to you
without the asks.
If you go to microsoft.com/accessibility
you will find conformance statements and 508 refresh
and WCAG and EN for our products anytime you need them.
I think that's important.
- Debbie.
Alright, any more questions?
Yes. (laughs)
What a great engaged audience. Thank you, guys!
It's really good to get these kinds of questions.
- Thank you so much. My name is Ferrell Khan.
I'm a former company called (speaks foreign language)
and first of all, thank you so much for the panel.
I learned a lot.
Again, when we talk about the publicity
I really doubt there is some kind of an expert
or their people are learning from their experience.
One quick comment,
and I think think this apply on private entities,
but also from the government folks,
which are mostly over here in this room
is at least from my experience, is sometime people
without disability they don't understand the impact
of not having a web accessibility website or application.
For example, if there is no alt tag on the image
sometime people who can see they don't understand the impact
of someone who cannot see, or blind person.
I think that's why it is really important
before you even work on any project try to show that impact
to your group of project managers, designers,
to overt tester, or whoever are apart of the team
so they can see or they can understand the impact
because sometimes if you don't realize the impact
you don't think that this is important to apply
in the code.
So that's my two cents.
My question is about these requirements, or guidelines,
or laws, or whatever we call those
is sometime there are so many ways
of meeting these requirements.
What my fear is that if I'm implementing a website
or an application and if I'm meeting one requirement
in one way, I have a fear that I should not be caught
by an expert on web accessibility that he or she's thinking
"Why you did not meet that requirement in his or her way?"
My point is that there are so many ways of meeting these 16
or more than 16 requirements.
I think that's where the VPAC comes
to justify how you are meeting
those requirements.
Beth.
- Can I say something about that just real quickly?
These requirements were built to be outcome based
and to not say "You must do this."
We used to have skip navigation.
Well, now we have something called blocks of texts,
skips blocks of texts and you could do it
with skip navigation or you could do it with landmarks
or you could do it with headings.
You want to be able to meet the requirement.
Because the problem is,
this is on that lessons learned piece,
Italy, when they adopted WCAG, too
in 2007 or eight,
it then required the techniques.
There's this thing in standards where something is normative
it's what is required and what's the law, if you will.
It's not literally the law.
So WCAG has just this one document that is the requirement
and then it has supporting documents.
Those supporting documents are the understanding,
the techniques.
Those things can change and be updated.
The standard can not change
unless you get a new standard, a new version.
Italy made the mistake of requiring specific techniques
and so then when technology changed
and people weren't using whatever it was anymore
then people were out of compliance
if they weren't using some outdated HTML element
that didn't exist anymore.
We learned that you can not require a specific way
to do something.
It's the reason why we wrote the standards
to be outcome based.
"Does it meet this?"
If you've got a new and interesting and different way
to do it because we got a new technology
then please do that.
So there are things we learned over time
"Yes, this is how we're gonna make tables accessible"
But now we have these things called grids.
We have 3D grids, right?
We're gonna have new and interesting and innovative ways
to meet these requirements.
Does it meet the outcome?
That's the point.
I think if you get into arguments with companies
about "Well they say we should do it this way."
"They say we should do it this way."
Does it meet the outcome.
That's the point.
The outcome is that it has to work for people
with disabilities and if they're using AT it has to work
for that, as well.
- That's great. Thank you, Katie.