aria roles and marking up important content

Wed Jun 17 05:20:45 UTC 2009

definitely some thorny issues here

one of the reasons I'm interested in this is the prospect of using  
the same technology that helps us present on little screens (whatever  
it turns out to be) to help us present view of info on screens of  
whatever size to people who want a simple presentation

from this viewpoint one would like the centrality/non centrality  
markup to be semantic, not size driven, and one would like it to come  
in as far upstream as possible

one would also like not the crude option of just tossing non central  
stuff, but making it available if needed in progressive disclosure  
(eg through a "more info" control

it could be that this philosophy is compatible enough with the ARIA  
view to justify using their tags

though I still think that some uses of the ARIA tags by others would  
not serve our other purpose of fitting on small screens

On Jun 16, 2009, at 7:16 PM, antranig at caret.cam.ac.uk wrote:

> This seems promising, but I'm wondering whether we are getting to the
> point where we have stepped over the threshold of burden we should
> reasonably expect to put on static markup? Clearly we would want to
> take the static world absolutely as far as we could, but it seems to
> me that once we get to this point of issuing device-specific switches
> in a newly coined markup namespace, we would want to start thinking
> about notations to express this one level back, in the
> "component tree" world?
> If there is a physical tag that we would wish to suppress completely
> on a particular device, it would seem better to set about making
> rules to suppress them during rendering. This of course creates
> issues of user agent detection and persistence, etc... it is always
> a bit disconcerting for me to paste URLs to people from Google Maps
> and find they contain junk like "&agent=opera" etc.... but this is
> at least evidence that this approach is workable for someone :P
>
> Cheers,
> Antranig.
>
> Quoting Clayton H Lewis <Clayton.Lewis at Colorado.EDU>:
>
>> there's an approach that's been hiding in plain sight (from me,  
>> anyway)
>>
>> among the ARIA roles are "main" and "complementary"
>> they are intended to do what we want, marking the more and less
>> central content in a page
>>
>> only one thing in a doc is supposed to be tagged "main", so that's
>> not very flexible
>> but lots of things can be tagged "complementary"
>>
>> since roles are attributes that CSS can select on, it is easy to
>> style out anything tagged "complementary"
>>
>> this very simple example page shows this:
>>
>> <html>
>> <head>
>> 	<title>Role Styling Test</title>
>> 	<style type="text/css">
>>    		div[role="complementary"] {display:none}
>>    	</style>
>>
>> </head>
>> <body>
>> <div role="complementary">
>> This is secondary text.
>> </div>
>> <div>
>> This is important text.
>> </div>
>> <div role="complementary">
>> This is secondary text.
>> </div>
>> <div>
>> This is secondary text not marked "complementary".
>> </div>
>> </body>
>> </html>
>>
>> A drawback to using "complementary" in this way would be that if we
>> were dealing with content someone else had tagged for ARIA, say with
>> a screen reader in mind, they'd be using "complementary" differently,
>> that is, NOT to mean "don't show this on an iPhone". so we'd have to
>> mess with their tags. We can use RDFa to coin our own role tags that
>> no-one else would use, as in this example page:
>>
>> <html>
>> <head>
>> 	<title>Role Styling Test</title>
>> 	<style type="text/css">
>> 		div[property="fe:complementary"] {display:none}
>>    	</style>
>>
>> </head>
>> <body>
>> <div role="complementary">
>> This is secondary text marked with the ARIA "complementary" tag. It's
>> visible in this version.
>> </div>
>> <div>
>> This is important text.
>> </div>
>> <div>
>> There follows some text marked with our very own "fe:complementary"
>> property. It should be invisible.
>> <div property="fe:complementary">
>> This is secondary text marked "fe:complementary".
>> </div>
>> </body>
>> </html>
>>
>>
>>
>> Clayton Lewis
>> Professor of Computer Science
>> Scientist in Residence, Coleman Institute for Cognitive Disabilities
>> University of Colorado
>> http://www.cs.colorado.edu/~clayton
>>
>>
>>
>>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

Clayton Lewis
Professor of Computer Science
Scientist in Residence, Coleman Institute for Cognitive Disabilities
University of Colorado
http://www.cs.colorado.edu/~clayton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090616/7997de1c/attachment.html>