W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2011

Re: Response to: ChangeProposals/DeprecateLongdesc

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 26 Aug 2011 18:00:59 +1000
Message-ID: <CAHp8n2nhH26phvXmkJQZmkXoUwoNT_r3_Z--2FmmJOC=4pfkvw@mail.gmail.com>
To: John Foliot <jfoliot@stanford.edu>
Cc: public-html-a11y@w3.org
On Fri, Aug 26, 2011 at 2:06 PM, John Foliot <jfoliot@stanford.edu> wrote:
> 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.

I'm not talking about what is specified - quite apparently the need to
retain markup has not been specified. But I am talking about what was
intended to be implemented and I keep hearing that it is implemented
inconsistently such that when it's not hidden, the structure is
retained and when it's hidden the structure is removed. Also, it seems
that the people that specified it actually intended to retain the
markup. So, that's where the disconnect and inconsistency is.


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

Widgets may need a more complex description, too. In particular we
keep coming across the problem that the language markup needs to be
retained - when flattened to just text, we will, for example, lose any
<span> markup with @lang that would get the screenreader to read it
out with the correct language model.


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

Yup, that's the inconsistency I am talking about.


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

The implemented reality is like this, but should it be like that? I
suspect rather not, see the @lang example above.


>> or we have to file bugs. This has nothing to do with the
>> @longdesc arguments.
>
> File bugs where? Against what?

Against the accessibility API mappings.


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

See example above. It's not just a problem for images. It's a general
problem with aria-describedby.


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

I'd hide any markers that are shortcuts to content on the page.
I'd hide video controls that are made in HTML to control a Flash
video, such as exemplified here:
http://www.povidi.com/YourTube/vid.py?id=kTvHIDKLFqc .
I'd hide anything that only makes sense to screen-reader users and is
in the way of a well designed display.


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

It's a nice theory and it works for the most simplistic sites. But in
practice I keep coming up against things that don't make sense to be
displayed on the page (context menu is also not on the page) without
further tools. There is plenty of evidence in practice that there is a
need to hide extra content. I think it's not constructive to ignore
that.


> 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).

Interesting - I hadn't really thought about the <details> element as a
way to hide content on the page. That would then be a nice combination
to work with @aria-describedby, which can link to a <details> element.


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

I've long since moved on from discussing @longdesc - for me it's a
matter now of understanding / identifying what @aria-describedby is
actually useful for as a general means for providing long descriptions
to elements. Does it deliver on what it was designed to be? Was the
requirement to remove structure and just present the text a poor
choice, reducing @aria-describedby to sharing all the problems that
@alt has? Is it too late to change that?


Cheers,
Silvia.
Received on Friday, 26 August 2011 08:01:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:44 GMT