RE: Split Issue 30? (was: Chair review of "Keep Longdesc Deprecated" Change Proposal)

Jonas Sicking wrote:
> 
> I agree we have two somewhat independent issues:
> 
> 1. Should ARIA attributes be allowed to point to @hidden elements.

ARIA attributes technically can point to hidden elements today - that is not
the issue (even though, as I have discovered via limited testing, what is
being pointed to is returned back as null content to in the screen readers I
tested, which is currently correct behavior) - the point being it is not
specifically disallowed as far as I can see. 

What is at issue is what happens to content not visible on screen: the
Accessibility APIs flatten the content to string text, as none of the APIs
were designed to support structured (marked-up) content. This point has been
brought forward numerous times to this Working Group, and no-one has been
able to show that this is not the case. It's not a browser issue, it's not
an HTML5 issue, it's an OS/API issue - and an issue out of scope for the
HTML WG.


Hidden content, whether referenced by ARIA attributes or not, cannot (should
not) support focusable content, as this throws of the long-held,
WAI-required need to maintain visible tab focus for sighted, keyboard-only
users (not just blind users, but any user unable to use a mouse):

  2.4.3 Focus Order: If a Web page can be navigated sequentially and the
navigation sequences affect meaning or operation, focusable components
receive focus in an order that preserves meaning and operability. (Level A)

     2.4.7 Focus Visible: Any keyboard operable user interface has a mode of
operation where the keyboard focus indicator is visible. (Level AA) 
source: http://www.w3.org/TR/WCAG/

Failing to provide support to these requirements in a W3C Recommendation
would be a willful violation of WCAG 2 - which is a very large discussion
that would be fraught with numerous pain-points. (Do we really want to even
go there?) 

However, at the same time it seems quite uncontroversial to suggest that
longer textual descriptions of complex images require (would significantly
benefit from) structured, marked-up text: anchors, headings, lists, tables,
etc. I have not heard or seen anyone dispute this point.


Content referenced via aria-describedby, aria-label, and aria-labelledby
also lacks the 'user-choice' of consuming or not consuming the longer
textual descriptions: the nature of those attributes is that they map to the
Accessible Name or Accessible Description, which are directly conveyed to
the Screen Readers for navigation and interaction purposes.


ARIA attributes and values are not being exposed to any user-group outside
of Screen Readers today - because only Screen Readers are availing
themselves to the properties of the Accessibility APIs. This could change if
browsers allowed sighted users the ability to 'discover' content 'tagged' by
ARIA attributes. Arguments by the "obsolete @longdesc" advocates have
repeatedly stated that longer textual descriptions should be available to
all users (agreed), yet referencing longer textual descriptions *ONLY* via
ARIA directly and completely shuts out those very (sighted) users argued as
also needing/wanting longer textual descriptions. This is a Browser problem,
not an HTML issue.


Currently this is a "hoped-for" solution that creates as many potential
problems as it seeks to solve. What continually gets passed over in this
protracted discussion is the role that the browsers must play in delivering
discoverable, user-choice-based, structured content. The mechanism of how
that content is marked-up, programmatically linked, etc. is not the real
issue - it is the user interaction model that needs to be delivered on. You
could call the attribute "Duck Soup" for all it really matters, without
browser support it's a moot point for any user outside of screen reader
users. For those users, @longdesc today will work in many of the major
screen readers today, and delivers on the 3 key user requirements.


> 2. Should @longdesc be marked as obsolete.

No. 

 * The HTML5 principle of backward compatibility suggest it should not. 

 * The current support in many Screen Readers to deliver the required
functionality of discoverabilty, user-choice and support of HTML rich
content today suggest it should not.
 
 * The emergence of "properly" coded @longdesc by actors such as the
Canadian Government (who seem to be producing a lot more @longdesc content
these days) suggest it should remain.
 
 * The willingness of commercial content producers, such as the recent
support voiced by educational publishers (for example) suggest that
well-coded @longdesc content will continue to emerge and grow.

 * Authoring tools currently part of the production tool-chain have made
adding @longdesc to images in WYSIWYG interfaces almost "idiot-proof"
(http://john.foliot.ca/wysiwyg_longdesc/) 

 * Alternative techniques ALONE should not be a reason to obsolete an
element or attribute from HTML5 - and here we have precedence: the <u>
element (underlined text can be achieved via CSS), <b> (bold text can be
achieved via CSS) and <i> (italicized text can be achieved via CSS).
Arguments stating that new semantics have been added to these elements that
make them valid is hollow: browser support for @longdesc would improve that
attribute significantly as well.


> 
> However it seems like issue 2 depends on issue 1. I.e. the case for
> marking longdesc as obsolete is stronger if ARIA is allowed to point
> to hidden elements.
> 
> Would it be possible to ensure that we decide on 1 before we poll on 2?

I really think that this is putting the cart before the horse.  Deal with
@longdesc now (restore it to HTML5), and then let's get the browser vendors,
the ARIA folk and other vested stake-holders together and work out a
longer-term ARIA solution that DOES deliver on discoverability, user-choice
and HTML-rich content support. There is already talk of minting a new ARIA
attribute for ARIA 1.1 that could do just that, but rushing towards an ARIA
solution (by promoting a broken and ill-conceived solution with current ARIA
attributes) today simply to satisfy a WHATWG desire to bury @longdesc is the
wrong way to address this contentious issue.

(Chairs, by way of that last statement, I too would support a splitting of
Issue 30 to a new HTML issue if it is to improve ARIA and does not include
obsoleting or "deprecating" longdesc from HTML5.)

JF

Received on Thursday, 9 February 2012 08:17:04 UTC