RE: 48-Hour Consensus Call: InstateLongdesc CP Update

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

Cheers!

JF

Received on Tuesday, 25 September 2012 01:05:23 UTC