Re: ARIA use in HTML other than for accessibility.

Hi Steve,

On 04/05/2015 10:47 , Steve Faulkner wrote:
> The paradigm in ARIA and in ARIA in HTML has always been only add ARIA
> if native semantics can't do the job of conveying UI information to
> users. If there is ARIA information in HTML making use of such
> information for more general purposes is not forbidden. But the addition
> of ARIA for purposes other than conveying missing UI information is
> actively discouraged.
>
> ARIA use in HTML makes sense when it results in concrete improvements in
> the user experience.

I think that the above is a good first stab at a summary. The problem I 
have with it, though, is that it may not be clear to everyone what 
constitutes UI in this context.

When one speaks of UIs, people typically envision the classic HCI bunch 
(buttons, icons, menus...) but those are not by any means the whole story.

The printed book, as a technology, has over time accrued its own set of 
user interface items. That's why we have typographical conventions: in a 
similar way that using tables for layout will break some expectations, 
if you typeset all of your paragraphs as titles or footnotes you're 
going to have a bad time.

Just like the HCI ones, the book UI items were initially visual-only. 
But they have been transitioning to the Web, and this is a great 
opportunity to ensure they are accessible.

An abstract, a footnote, a chapter, a table of contents are important 
user interface items in a publication. I don't think that exposing those 
amounts to some sort of "semwebisation" of ARIA (I suspect that's 
conflating the specific publishing proposal with something broader and 
essentially different).

This doesn't mean that they shouldn't be reviewed — on the contrary. But 
it does mean that taking publication UI into account does not of itself 
turn ARIA into some sort of dumping ground for crazy ideas.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 11 May 2015 10:09:51 UTC