RE: 48-Hour Consensus Call: InstateLongdesc CP Update

Maciej Stachowiak wrote
> 
> When you said this in an earlier email:
> 
> "it comes down to 2 paths forward as I see it: one is that we mandate
> something that browsers will continue ignore, or we actively engage
> them in
> crafting the solution, one that meets all of the user requirements."
> 
> I assumed you were dissatisfied with the current level of browser
> support, and that you wanted to see more widespread support for
> longdesc than that. If you are satisfied with having longdesc support
> in Opera, iCab, IBM HomePageReader and some screen readers, then of
> course you do not need to persuade anyone else to implement, or for
> that matter engage anyone in crafting the solution. I am confused
> though, by the contrast between your two statements.

Hi Maciej,

Thanks for the question. Allow me to explain (with the proviso that this is
my personal opinion).

It's not about my level of satisfaction, it's about what is useful for end
users. Yes, I would like to see more wide-spread support for longdesc, but I
am not totally dis-satisfied at what support we have today for the core user
group that requires longer textual description; those who cannot see the
images at all.

Today, for non-sighted users who need longer textual descriptions, they can
use a third-party tool such as JAWs to access that content. They can
encounter an image, and be informed of the presence of additional
descriptions, and then choose to consume it or not consume it. What they get
today is a POSH document (Plain Old Semantic HTML), which, when you can't
see, is plenty good. (Flatten that to string text and don't even bother).
This works well in browsers that expose the @longdesc value to the API, and
by experience that means IE and Firefox on Windows in coordination with one
of those screen readers delivers a working solution today. That's a sizable
amount of the core user-group covered right there.

Providing support to sighted users is a bit more problematic. There is a
general agreement that some (many?) sighted users would also benefit in
having access to this same text, but today few browsers provide access to
that - with a few exceptions. To fill the void, 3rd part developers have
created browser plugins that make the presence of @longdesc content known to
sighted users - and this is a conscious choice by those users (because they
chose to install the plugins in the first place). The key difference here is
that it's not something that the author needs to visually provide (and thus
it won't impact on her design), but if a specific user chooses to "change"
that design to meet their specific needs, they can, by changing their user
settings. This is tried and true UD, and the basis of a lot of the
accessibility support that Apple has rolled out over the years.

Do I wish the browsers would implement a native behavior along the lines of
what the exemplar plugins are demonstrating? You bet. Screen readers like
NVDA aren't *against* @longdesc, but Jamie and Mich told me personally that
they don't want to be creating new user interactions - they want to map to
existing interactions in the browsers. I think that's fair enough, but
without those native interactions, NVDA sits on the sidelines. Am I
dissatisfied by that? Yup, but I've long learned that 70% good is better
than 0% good, and so everything is relative.


But is that kind of enhanced availability to sighted users critical in
retaining @longdesc in HTML5? No, not in my opinion. It would be helpful,
and I am of the opinion that should a browser seek to do something, however
fledgling it might be, to take on this task that it would be well received,
even if not perfect.

However I hear browser vendor reps saying that they don't want to take on
that task, they want to re-engineer a better approach to providing longer
textual descriptions. OK,  I can back that - I have already. So don't do
anything with @longdesc, but please, don't break what existing
implementations we have today. Making @longdesc obsolete is a serious nail
in that coffin, and for what? It becomes a backward step, in that to now
author an image with a longer textual description, you have to have the
latest and greatest (beta) solution, and even one version behind that curve
is completely shut out from the new functionality - with no conformant
fallback mechanism in place. And unless all of the browsers commit to
rolling out the new functionality simultaneously, there will be an
additional period where support will be spotty, yet another factor to deal
with. How can that be putting disabled users first?

Retaining @longdesc as conformant allows the growing body of content
creators that *do* actually author longdesc correctly (Pearson/NCAM/et. al)
to continue to be conformant - they too can change their doctype from HTML4
to HTML and be using HTML5 - one of the promises of HTML5: backward
compatibility. They too can use the HTML5 validators and work towards fully
conformant HTML5. How is that bad? 

Meanwhile, if the browser vendors are serious about tackling this problem,
the olive branch has been extended by many to pursue that work - together.
We can craft that solution, and let it deploy in the normal scheme of
things, which I have already suggested takes between 3 and 5 years. That
sucks, but that's also honest. (I will also note that the draft
aria-describedat looks remarkably like @longdesc, with the exception of
better execution detail - a point that Silvia Pfeiffer notes is critical)


I made mention of the CR Exit Criteria because even today, with no effort
from the browsers to do anything but maintain the status quo, @longdesc has
enough support that it's not a feature at risk - something we cannot be sure
would be available to the newly minted wonder-solution.  Is that good
enough? Yes and no. It's good enough to exit CR, but it's not as good as if
every browser supported the feature natively. But for the core user-group -
non-sighted users - it remains all systems go. TODAY.

I hope you can see why striving for better while maintaining the status quo
need not be mutually exclusive - which is what appears to be happening.  We
have one group insisting that the only way forward is to continue to keep
@longdesc non-conformant, and another group (of which I have no issue
claiming to be part of) that says this is simply nuts. How does making
@longdesc non-conformant make crafting a better solution any easier? Why
does these two states have to be linked together? That's a serious question
BTW, and one that has been asked by others (notably Leonie Watson, who asked
why take away the bike when the car isn't ready?)

So in my quote above, I'm not so much advocating that we mandate browsers do
anything more (or less) than they are doing today (but I wish they would,
and the new spec text in Laura's CP shows a way forward), but that we
mandate that @longdesc be conformant none-the-less. I think that browser
vendors who don't try to support @longdesc are foolish - as my granny would
say they are cutting off their noses to spite their face - but I don't own a
browser vendor company, and so my opinion is just that, opinion. If (and I'm
not pointing fingers) Safari doesn't want to support @longdesc, then don't -
you haven't to date so it's not like you are stepping backwards.  However,
with Laura's CP, there is a hint of what could be done, and maybe, just
maybe, you might want to take another look at what's actually there.

Is that any clearer now?

JF

Received on Wednesday, 19 September 2012 03:37:19 UTC