E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Asa Baylus
Date: Fri, Feb 20 2015 3:20PM
Subject: Build for the bugs?
No previous message | Next message →

I recently joined this list and have noticed a number of discussions surrounding bugs in AT and how to code solutions around these bugs.
It reminds me of the browser wars.

My question is... Should we be coding for the browser / AT or for the spec?

- Asa

Sent from my iPhone

From: John Foliot
Date: Fri, Feb 20 2015 3:23PM
Subject: Re: Build for the bugs?
← Previous message | Next message →

Yes.

JF



>

From: Bryan Garaventa
Date: Fri, Feb 20 2015 4:26PM
Subject: Re: Build for the bugs?
← Previous message | Next message →

I always recommend adhering to the spec, because as support increases, your widget will only work better as time goes on, whereas if
you try hacking a solution for a particular browser/AT combination, it will likely only break as proper support is refined.

From: Léonie Watson
Date: Sat, Feb 21 2015 3:40AM
Subject: Re: Build for the bugs?
← Previous message | Next message →

" 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

From: Cliff Tyllick
Date: Sat, Feb 21 2015 10:42PM
Subject: Re: Build for the bugs?
← Previous message | Next message →

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 ADDRESS 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
>
>
> > >

From: Asa Baylus
Date: Sun, Feb 22 2015 6:59AM
Subject: Re: Build for the bugs?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
>>
>>
>> >> >> > > >

From: Jon Metz
Date: Sun, Feb 22 2015 9:22AM
Subject: Re: Build for the bugs?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> >>
> >>
> >> > >> > >> > > > > > > >
> > > >

From: Olaf Drümmer
Date: Sun, Feb 22 2015 12:29PM
Subject: Re: Build for the bugs?
← Previous message | Next message →

> "when to apply accessibility"

a good idea for example is to only use acronyms accompanied by an explanation. Despite being in the software business I had to look up SDLC.

Now, normally I would send this privately to the poster. But as it is illustrates that 'we' (including myself!) see accessibility deficiencies especially well when they are caused by others, I believe it's worthwhile to put it on the table on this list.

I think it is highly undefined (sic!) what it means to "see[ing], from the beginning, that accessibility is a fundamental requirement." I also dare say that for over 90% of people dealing in accessibility it equates to screen reader support for use by blind people (and thus missing out on the other 98 or 98 percent of people with some limitation in functioning). What's still missing is a coherent overall approach (so that most of us software engineers, designers, document producers, … for example could get most of the important stuff right early on, without having to interrupt daily business for a year to study accessibility).

Olaf

From: _mallory
Date: Mon, Feb 23 2015 1:11AM
Subject: Re: Build for the bugs?
← Previous message | Next message →

On Sun, Feb 22, 2015 at 08:59:18AM -0500, Asa Baylus wrote:
> So what happens when we code to resolve a specific bug and our bug fix breaks the spec?
>
> -Asa

With browser bugs, many of us comment the hell out of our weird
code.

If you use a well-known prefix like //XXX or //FIX, you can find them
later easily to remove the moment you can get away with it.

If say JAWS had a bug that NVDA didn't and you could not possibly write
code that worked for both of them? With browsers, popularity was
indeed a factor: if the Good Browser was Opera, it got the shaft :(
But usually it's one having a bug and the rest mostly conforming, so
then it's looking at "what do the clients use" and "does this seem like
it will be fixed by the vendor soon" and "does this vendor auto-update?"

At least, those are the kinds of questions that we go through.
cheers,
_mallory

From: Steve Faulkner
Date: Mon, Feb 23 2015 3:25AM
Subject: Re: Build for the bugs?
← Previous message | No next message

If the bugs are due to browser implementations of accessibility
information, suggest filing bugs
http://www.paciellogroup.com/blog/2014/06/filing-bugs/

Likewise for AT, though the path to doing this is not always so simple.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;

On 20 February 2015 at 22:20, Asa Baylus < = EMAIL ADDRESS REMOVED = > wrote:

> I recently joined this list and have noticed a number of discussions
> surrounding bugs in AT and how to code solutions around these bugs.
> It reminds me of the browser wars.
>
> My question is... Should we be coding for the browser / AT or for the spec?
>
> - Asa
>
> Sent from my iPhone
> > > >