RE: Response to: ChangeProposals/DeprecateLongdesc

Silvia Pfeiffer wrote:
> 
> I am not arguing about @longdesc here. I am arguing about the problem
> that aria-describedby was developed to allow exposing the structure,

No, it was developed as a means for DHTML/Web 2.0/AJAX/whatever widgets to
convey an AccessibleDescription to the Accessibility APIs. There is no
mention, and never was as far as I know, about exposing structured content
to the end user. I welcome you to provide evidence to the contrary.


> but it seems that all implementations are removing it.

No implementation is removing anything - they are all doing (or should be
doing) what is specified in the ARIA spec and Accessibility APIs - it is
providing an AccessibleDescription so that this "thing", this widget, can
be described. Widgets don't need hyperlinks as part of their description;
widgets don't need list mark-up or table data mark-up to be described.
Complex images do.

If you want aria-describedby to convey full mark-up, then that mark-up
must be 'on screen' and visible to all - and it can do that today, as
implemented. If you move the text (including markup) off screen, then it
is interpreted as flat or string text.


> So, either we
> have to fix up the aria-describedby spec to meet the implemented
> reality

The implemented reality is, or should be, that when text is not visible on
screen, aria-describedby treats it as string text.


> or we have to file bugs. This has nothing to do with the
> @longdesc arguments.

File bugs where? Against what? 

Silvia, I know you are saying that this isn't about @longdesc, but the
only time this is really a problem is when you try to make
aria-describedby become a stand-in for @longdesc. Any other time, in any
other instance that I can imagine, this is simply not a problem.  Can you
give me an example where this would be a problem? (And again, remember
what aria-describedby is supposed to be doing - providing an
AccessibleDescription to the AAPI, not giving us multiple paragraphs worth
of prose and other marked-up content)


> 
> This is indeed a problem that we need to address. It's the same with
> any content that we want available to screenreaders but not exposed
> otherwise. 

While I agree that this is a problem, the problem I see and the one you
are seeing is not the same problem. 

I am not a huge fan of hiding stuff from users, as often that creates as
many problems as it solves. What 'stuff' do you think should be hidden
from cognitively challenged users that should be exposed to screen-reader
users? What 'stuff' should only be made available to screen-reader users,
and why are they getting special treatment?  It's a very slippery slope...

If you go back to my initial Draft response to Jonas, you will note that I
specifically mention that the current "issue" we have with @longdesc, and
the one that is apparently the burning reason to banish @longdesc from the
face of the earth, is the one of "lack of discoverability" by sighted
users - or as those opposed to @longdesc will call it "hidden" or "black"
data.  So generally, hiding stuff that cannot be easily 'unhidden' is just
bad authoring practice, and on this point I am actually in agreement with
@longdesc opponents. 

As I've repeatedly said, and you have conceded, this is a problem with the
browsers treatment of @longdesc, not the mark-up; the proof is that many
screen readers *do* do something useful (and, meeting the discoverability
and choice requirements) - they announce the presence of a longer
description, and wait for further instructions from the user. Furthermore,
when the screen reader user chooses to pursue the longer description, that
longer description is displayed, on screen, with full semantic mark-up.


> We see that happening with things that are positioned
> off-screen all the time, or hidden behind other elements, or made 1x1
> px large. Do we have a general remedy for this problem? Isn't
> tabindex=-1 the solution here?

While I do come across this, I would be loathe to classify it as "all the
time", and generally it is on sites that have numerous egregious
accessibility issues of which hidden content is but one problem.  

However, recognizing that there may be times when you may want to conceal
but then reveal content to end users, HTML5 has the <details> element,
which as specced is sort of a "show-hide" widget behavior (that *is*
discoverable), so rather than hide stuff behind other elements or other
hacky tricks, there is now a specified method to deliver this
functionality (now, if only, once again, the browsers actually delivered
on this). At the risk of angering some of the more hard-core @longdesc
proponents (and yes <grin> there are some that are more hard-core than I),
under *some* instances (and once we get browser support) I believe
<details> *could* be one vehicle for providing longer textual
descriptions, *if* the graphical design of the page allowed for something
like that. But I hasten to add, that would in no way diminish the need to
retain the mechanism of @longdesc.

As for tabindex=-1: using tabindex=-1 has 2 effects: on tabbable
(focusable) content it removes it from the tab flow, and on normally
non-focusable content it allows focus - useful for scripting. It would
have hugely negative implications for screen reader users as it would
break their ability to access the content. So unfortunately, that isn't a
solution either.


> 
> 
> >> It can't be held against the attribute that an implementation has
> >> interpreted the specification more tightly than interpreted. It just
> >> means that the specification needs to be made more explicit and the
> >> implementations adjusted.
> >
> > Again, this seems like a lot of additional work just to acquiesce to
> a
> > few's mistaken drive to obsolete @longdesc.
> 
> I've side-tracked a bit and am just argue about the value / non-value
> of @aria-describedby by now. Apologies.

No worries Silvia, and I hope I've not come off too harsh in my response.
It is useful to challenge and test all assertions to be sure of what we
are saying, and this thread has afford such an opportunity, so thanks for
that.

> 
> 
> > To turn your last comment on
> > its edge:
> >
> > It can't be held against the attribute (@longdesc) that most GUI
> browsers
> > have failed to bring forth an implementation that was useful for all
> (and
> > not just the non-sighted). It just means that the specification needs
> to
> > be made more explicit (@longdesc must be discoverable to all, and
> able to
> > be acted upon by all) and the implementations (browsers) adjusted.
> >
> > Right? <grin>
> 
> I would, in fact, totally agree with such a statement. :-)

:-)

JF

Received on Friday, 26 August 2011 04:06:41 UTC