Re: 48-Hour Consensus Call: InstateLongdesc CP Update

On Tue, Sep 25, 2012 at 11:04 AM, John Foliot <john@foliot.ca> wrote:
> James Craig wrote:
>>
>> > Also, you did not comment on the link (or interactive content -
>> > audio/video are not interactive content, per HTML5). Just tested now:
>> > If I open a link inside that frame, then it opens inside that frame.
>> > That's lots of things happening behind an image. We have just been
>> > through a round about whether hidden="" can be used as an accessible
>> > container, and what the A11Y TF protested on was precisely the
>> > potential for creating a whole, hidden world that only blind users
>> > could see - so to speak.
>>
>> It would seem you're concerned that activating a link in an iframe
>> would default the frame target to itself. That's a valid concern, but
>> may not be a problem in practice, and there are ways to prevent that
>> accidental behavior. The author could use a target attribute, the user
>> could trigger a "open in new tab" functionality, etc. It may also be
>> appropriate for this page to open links in the same target. In any
>> case, it's something to consider, but I don't think it'd be a concern,
>> so to speak.
>
> Hi James,
>
> I'm more concerned about a link in that hidden frame, or perhaps 3 or 4
> links, and how/what will happen with tab-focus.  For a screen reader to be
> able to afford the user the ability to fire a link, it must first receive
> tab-focus. Yet those tab-focusable links are hidden to the sighted user.
>
> How do you reconcile that with: 2.4.7 Focus Visible: Any keyboard operable
> user interface has a mode of operation where the keyboard focus indicator is
> visible. (Level AA)
> http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-v
> isible
>
> I have posed this question numerous times now, and never received an answer
> (it is also the basis for my current Formal Objection towards the Issue 204
> Decision, where those "links" can now apparently be hidden and still
> semantically rich - i.e. active.).

John,

you can't have it both ways:

Either it is visible content, then it is created by Web Devs to be
visible and thus also accessible.

Or it is accessibility content, then it is not visible to anything but AT.

That the content in the document that you are referencing from
@longdesc can be both, does not mean that it will be both through a
single attribute. If our main use case is accessibility - as I
understand it is - then the second use case is the important one and
we need an a11y attribute (preferably an @aria-attribute). In this
case we can encourage the Web Dev to further also expose the document
visibly through other markup means. I think this is the only realistic
way of solving this double use case.

Regards,
Silvia.

Received on Tuesday, 25 September 2012 01:51:58 UTC