WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Build for the bugs?

for

From: Jon Metz
Date: Feb 22, 2015 9:22AM

Hi Asa,

So what happens when we code to resolve a specific bug and our bug fix
> breaks the spec?


I think this question is something that should be considered long before
the project planning process. In my experience, a lot of creatives and
developers run into the conundrum regarding "when to apply accessibility".
It's often seen as this separate and often annoying criteria that has to be
somehow reconfigured into the final product, which inevitably means hacking
and breaking the product so you can get it to fit just right. In the end,
the designer that originally thought up this awesome high-tech toy and the
developer team who actually made it work are left sulking in the corner,
kicking dust, exclaiming that "Nobody loves them."

It's heartbreaking, but something we've all seen time and time again.

I think the main problem that you and many other developers will continue
to have is not seeing, from the beginning, that accessibility is a
fundamental requirement. This should be determined within your SDLC policy
at a functional, organizational level. It should be addressed very early on
so when you encounter a situation that looks out of place, you have
provisions that can catch it.

A huge problem I encounter with clients is when they take for granted the
sort of things they assume everyone will do, because they don't break it
down far enough. Other situations include not thinking too greatly about
who their audience really is. And still more fail to really wonder what
would happen if a particular part of the audience lacked a characteristic
that they assumed everyone would have.

Specifications are meant to help to identify ways to compensate for those
limitations. So if your software works with specs, then you are at least
meeting the requirements that are set forth. But you might be doing
something and have NO IDEA why you just did it. For that reason, your SDLC
policy should set parameters that identify *why* it's important to do those
things.

That way, instead of asking if something is aligned to the spec, you can
ask, "but can someone who is deaf/blind/dyslexic understand what's going
on?"

From a project management perspective, identifying the requirements of the
project should help you to assess the risks that you don't know yet by
asking the what-ifs of the whole shebang. Your SDLC should tell you what to
do when you encounter those "Oh-noes", and your planning should trap all
that accessibility goodness long before the design gets implemented. At
that point, you end up with people who naturally see this as a fundamental
truth and less worry about whether something will work with today's
iteration of AT. From here, you're less likely to encounter the whole,
"Ugh. Accessibility means we need to stifle creativity." Instead you'll get
more, "What's a more creative way to solve this problem??"

When asking yourself if you should design for AT, ask yourself how you feel
about designing for IE6. At some point in the conversation, you just need
to put your foot down and say: "I'll handle the specifications this way.
My audience will need to do one thing. AT vendors will conform to another".
In the end you'll have an accessible product that meets the requirements
and make gobs of money. When that happens, you can come back here and say
how awesome Jon Metz is (but you should probably do that anyway).

Hope this helps.

Jon

On Sun, Feb 22, 2015 at 8:59 AM, Asa Baylus < <EMAIL REMOVED> > wrote:

> So what happens when we code to resolve a specific bug and our bug fix
> breaks the spec?
>
> -Asa
>
>
> > On Feb 22, 2015, at 12:42 AM, Cliff Tyllick < <EMAIL REMOVED> > wrote:
> >
> > The real answer? Neither.
> >
> > We're coding for the people who will use our site, our app, our
> software, or whatever.
> >
> > So we start by coding to the specs to ensure that our code is robust.
> And then we look at the tools available and code to ensure that they can,
> in spite of their deviation from the spec, be used to access the content
> and interactions we have built.
> >
> > Finally, we look to the direction in which the spec is headed. If
> possible, from that toolset we add enhancements that further improve the
> experience for at least some of the people who will use what we have built.
> >
> > And if we only ever created one thing, we would continuously improve it
> as the changing world makes those improvements possible.
> >
> > So, yes. Both. Neither. And then some. 😉
> >
> > Cliff Tyllick
> > Austin, Texas, USA
> >
> > Sent from my iPad
> >
> >> On Feb 21, 2015, at 4:40 AM, Léonie Watson < <EMAIL REMOVED> > wrote:
> >>
> >> " My question is... Should we be coding for the browser / AT or for the
> >> spec?"
> >>
> >> In a perfect world, UA would conform to specs, developers would code to
> >> specs, and users would know how to use things in the one built by the
> other.
> >> In reality we have to cope with circumstances that are less than
> perfect in
> >> all three cases.
> >>
> >> The decision whether to code for one or another comes down to what
> you're
> >> building, who you're building it for, and what it needs to be supported
> by.
> >> There isn't a simple answer to that unfortunately, although JF's "yes"
> does
> >> sort of sum up the situation!
> >>
> >> Léonie.
> >>
> >> --
> >> @LeonieWatson Tink.UK Carpe diem
> >>
> >>
> >> > >> > >> > > > > > > >
> > > >