Re: Using title for ARIA name is impractical!

** intro

These are tough tradeoffs.

If we do define @aria-name, then in SVG we have to tell authors
not to use it and to use svg:title instead.  But how many SVG-at-root
pages are there on the Web?

Conditional content should be in elements.  The SVG model is
what we would like to be migrating the web toward.  But we
have made lots of compromises with getting things to be an
incremental change in current practice.  This would be setting
up ad-hoc features that set precedents that we would rather
see built more systematically.  But is it any dirtier than
what we are working with?

In the details below you will see lots of blather presenting
the argument against changing from our present markup profile
to a dedicated @aria-name and a brief 'pro' section just to
make clear that I do see two sides to the question.

** details, con

On 26 Jul 2008, at 5:25 PM, Loretta Guarino Reid wrote:

>
> Aaron,
>
> While I agree that this needs to be thought through carefully, I
> disagree that using hidden labels is desirable (although there are
> situations where it may be necessary, too). Hidden labels don't
> degrade gracefully in the absence of  CSS. We are taking advantage of
> the current behavior of screen readers, but there is nothing inherent
> in "hiding" text by positioning it offscreen, in contrast to hiding it
> with various values of display, that means one should be visible to
> assistive technology and the other shouldn't.

Check me, Loretta, but I think that the WCAG2 technique we keep citing
for hiding things with CSS uses positioning and not display because
of a failure of the 'display' -driven technique to be interoperably
implemented in browsers.

> I think it would be much cleaner to have a well-defined ARIA attribute
> for the purpose of providing a name when there is no visible label,
> for whatever reason.

Not an attribute.  Anything that should be shown to users, even
sometimes, should be in an element to allow for things like <ruby>
@lang, <abbr> etc.  We need to fix the control path for the user's
view control, not just add more special-case data fields.

>
> Here is another example where I think this type of support would be
> useful: Phone numbers in the US are often represented by three fields
> (area code, prefix, suffix). A single visual label is adequate for the
> 3 fields, but each should have a name exposed to AT.

The screen reader is just one user that gains by access to the sub-field
names in such a record datatype.  How many times have you received
instructions on how to dial international numbers (in my case from
my rented Euro-zone mobile phone) that were totally confusing because
they don't deal explicitly with codes for (access to global dialing)
(country code) (part), (part), ...?

My point is that this is the standard data-engineering description of a
structured datatype -- the metadata that go with any machinable data.
There are many more users that need this, even though for most retail  
web
hits it can be elided.  For personalization on the Web, we need the
drill-down capability for the user-directed rendering to have access to
the metadata level that it needs.

Meanwhile, for WAI-ARIA we have had to punt on all treatment of  
datatypes
because of a lack of a settled convention in the base technology.  There
is XSD and RELAX-NG and DTD but HTML as practiced doesn't follow any
of them.  The closest thing to datatyping with any sort of fidelity in
practice (other than applications that are interfaces to data  
engineering
tools) may come from microformats.

Which all leads me to the "better fighting against the good" aspect of
this debate.  WAI-ARIA is a proposal for an incremental change to a
very widely used and very sloppy technology known as HTML+script+CSS (It
is defined in such a way so you can use it in XML-based formats as  
well).

To gain widespread, interoperable use our proposal has to be lean and  
mean.

For authors or sites to use it consistently it has to be implemented  
consistently
in browsers.  To be implemented consistently in browsers, it has to  
be very lean.

To keep it lean, we have to be pretty mean about rejecting added  
fields that would
make it better in this adapted UI or that one,  but don't build the  
universal
design architecture from the ground up to (a) serve different PWD  
user groups
equitably and (b) generate "curb-cut-effect benefits" in the  
mainstream market.

So I'm still inclined to say "the impulse to hide a label is usually  
wrong,
and the pain of the techniques it takes currently to hike with CSS  
(when you really
want an invisible label) is unfortunately the best we
can do for you in the imperfect world of actual Web technology."

As far as the "parts of the phone number" use case, this is just like  
the
problem with dates.  We have backed off from looking for real  
metadata about
record structures like this, but you can offer something of the  
nature of an
xforms:hint using @describedby.  The hint text for dates often reads  
something
like

mm/dd/yyyy

and the hint text for a phone number could read something like.

+country(if-in-country)prefix-suffix

** pro

The flip side of all these arguments is that an accessible name for  
e.g. a
section or a data field is so important that maybe I should accept  
the 'dirty'
attribute solution and the insistence that conditional content be in  
elements
is the 'better' that is blocking our finding the "good enough" right  
change
proposal.

** summary

In my mind, the @title option for accessibleName is a repair.  It is  
there for
the author that didn't care about accessibility but did put a  
tooltip- a transient
legend, on their page feature, rather than a persistent label.  In  
this case the
fleeting legend is likely to be better identification for the page  
feature than
nothing at all.  So allow it in the browser algorithm to populate the  
API.

If the author cares to craft a good name for the page feature, and  
they don't
want it to show (even after thinking twice about this), they should  
bite the
bullet and go with a CSS-hidden element to hold that conditional  
content.
That's my personal understanding of the reasoning behind the current  
design.

But there's an alternate model of "future history" where we introduce  
@aria-name
and a few access-aware authors use it and other authors discover its  
broader
utility and expose the @aria-name value with CSS media queries and  
generated
content rules and the document fabric is tortured, "growed like  
topsy" but the
usage is accessible in the end.

Al

> Loretta
>
> On Sat, Jul 26, 2008 at 7:03 AM, Aaron M Leventhal  
> <aleventh@us.ibm.com> wrote:
>>
>> MSAA has accName and accDescription from before the days when  
>> their were
>> relationships like labelled_by and described_by, which newer APIs  
>> like ARIA,
>> IA2 and ATK/AT-SPI all have. It allows you to point to a real  
>> label. You
>> also need accName to expose alt for images.
>>
>

Received on Monday, 28 July 2008 14:29:44 UTC