Re: aria-describedat

Nice work! I have some feedback, too.

I'll start with a nit: there are several typos where you've written
"descibedat" (notice the lack of the letter "r").

And some more comments inline below:

On Thu, Mar 22, 2012 at 6:12 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>> FIRSTLY: In the example code, please change the following URLs,
>>    aria-describedat="http://example.com"
>>    aria-describedat="http://example.com#description"
>>
>> into for example the following ones:
>>
>>    aria-describedat="http://example.com/page"
>>    aria-describedat="http://example.com/page#description"
>>
>> Justification: There are enough of dumb and useless instances of
>> @longdesc where the URL points to a top level domain that obviously
>> does not contain any description.
>>
> I agree that is dreadful but that sounds more like providing better
> authoring guidance. We can put that in the authoring practices for ARIA 1.1.

I think we should do both: make the change in this doc and also
consider adding authoring guidance into ARIA. It's a nit (again), but
one that supports better authoring.

You just need to change the first canvas example to:
<img src="shalott.jpg" alt="A painting inspired by Alfred Tennyson's
poem The Lady of Shalott" aria-describedat="#description">



>> SECONDLY: Why not use the same element - <img> or <canvas> - in all
>> examples? Then you can demonstrate different ways to present the long
>> description: 1. An entire separate page. 2. A specific element on
>> another page. 3. A specific element on the same page. Justification: It
>> is often simpler to discover patterns and differences, if the same
>> element is used - and seen - from different angles.
>>
>
> We could. Ultimately, examples will go into the authoring practices guide.

I agree with Leif - that would make this document more readable (and
again: it's a nit - nothing substantial).


>> FOURTH: Fallback questions: The URL in the canvas example points to an
>> element in the canvas element' fallback. Could the same method be used
>> for pointing to the fallback of an <object> element also? And why not
>> let the URL point to the canvas element itself rather than to a child
>> element in the fallback? And does the element her serve as something
>> that explicitly tells the AT/UA to reveal the fallback? Would it not
>> use the fallback without the URL? If it would use it anyhow even
>> without the URL, why include the URL? I know that screenreaders have
>> problems with reading the fallback of <object> - they often don't read
>> it, and to work around this, one can e.g. use aria-describedBY to point
>> to the fallback. So is this the reason why you have this URL - to
>> workaround screen reader issues? Or, perhaps screen readers should
>> behave this way: You should still explain why it is necessary to do
>> this in order to make the screenreader read the fallback.
>>
> I think a problem with using fallback content is that it is obscured. A
> browser, that brings up the fallback fragment would show it hidden unless we
> provided separate requirements which are a SHOULD at this time vs. a MUST. I
> think we either do this or we require the authors to point to content that
> is visible to all users.

Actually, I think this is a general question that we need to clarify:
What happens if aria-describedAt points to hidden content? Will it be
unhidden for AT? I think it should be. And it should not be flattened,
but retain its structure.

Basically, I think what we need is a kind of "overlay"-functionality
for the document/fragment linked to. As soon as the link is activated,
that document/fragment becomes the new document temporarily with a
simple means to return to it. The best visual rendering of this that I
can think of are "overlay" or "popup" or more generally a "modal
window". If we render it in this way, then it's not added to the
browser history, does not move you away from the current document, and
keeps the focus until you're finished with consuming the description.

While we do not need to require the implementation to be done in this
way, it would be good to recommend such a rendering approach.

So this means we have:

* a visual indicator on top of the element (maybe an icon such as the
one I found here:
http://adobeperson.com/wp-content/uploads/2008/11/photoshop-study-book-logo-icon6.gif)
- this indicator would only appear briefly when having mouse focus or
keyboard focus and disappear again; it would be in the shadow DOM and
people would be able to style it

* an additional link in the context menu, as well as an announcement
of its availability to the screenreader with a defined keyboard
shortcut to activate it (we'll have to think about what to do with
touch devices)

* a modal window display when activated with a "close" button

Does that make sense?

Cheers,
Silvia.

Received on Wednesday, 21 March 2012 21:25:10 UTC