Implementing ARIA
Home / Site Building & Testing / Implementing ARIA
Hi,
Now IEv8 supports ARIA I've started looking into implemetation and validation but getting hardly anywhere.
It appears that for a XHTML document to validate the aria roles must be added post load via javascript. I tried this:
| Code: |
| document.getElementById('content').role="main"; |
No JS error but it doesn't appear to work.
Does anyone have any references to ARIA implemetation?
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share: 
I've implemented a simple tabbed interface with ARIA. It's not a very complex use of ARIA but might be helpful._________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
Thanks Jim,
That got me over the first hurdle:
| Code: |
| document.getElementById('content').setAttribute('role','main'); |
Next it'll be live areas.
mike foskett
_________________
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
Remember not to repeat your document semantics. If you're already using <h1> for the start of main content, role="main" is repetitive information.
Indeed, pretty much any use of ARIA in static markup will be repeating semantics which HTML already has.
Steer clear of introducing unnecessarily complicated interfaces just because "ARIA makes it accessible". EYG's tabbed sidebar is a good example of ARIA being used for evil.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Ben Millard (Cerbera) wrote: |
| Indeed, pretty much any use of ARIA in static markup will be repeating semantics which HTML already has. |
Don't see how using contentinfo as a role on a div containing normal footer info is repetition. Or marking a nav list as role=”navigation” , for example.
_________________
www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum
International Lothario (retired)
Share:
If you're using XHTML anyway, you could always add the ARIA attributes as a DTD subset and code them directly into your markup. Conforming browsers and validators should recognise them just fine.
However, see the ongoing discussion about HTML vs. XHTML before you consider this. Generally speaking, you should avoid using XHTML for web documents. (Despite disagreements on certain particulars, Ben and I concur on this point.
)
Share:
My reply got a bit long, so I blogged it: ARIA in Static HTML. I reckon ARIA adds nothing useful to static HTML and its syntax makes it inefficient._________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Thanks for that blog post Ben; it cheered me up on a gloomy morning.
I admire, but don't share, you faith that The Relentless March of Technology will allow artificial intelligences to guess at authorial intent, and that browser manufacturers will put loads of heuristics into every desktop and phone browser, screenreader etc.
You think role="contentinfo" is inappropriate for footers, because footers are "mostly" about the whole site, whereas contentinfo is about the parent document.
Well, if you have some data that is about the whole site, then it is also about the parent document. So I don't see a problem. (And why is a link to contact info not metadata about the site?)
I do see a problem with your belief that heurisitics can determine a div containing "footer" information. Some of them may not be at the bottom of the page.
Even if it is at the "bottom of the page", it may not be bottom of the source code, so your algorithm would presumably have to know how CSS has laid out the page to determine what's at the bottom of the page. It would probably need to wait to check that no scripts have inserted information, too.
It strikes me that your argument is also an argument against the HTML 5 footer element. Why have a new element when your in-browser A.I. can work out that it's a footer from its visual position and its contents, regardless of whether they're in English, German or Swahili?
Obviously, every browser would need to implement the same algorithm in order to ensure cross-browser compatibility, so there needs to be a rigorously defined, open-standard for identifying a footer. Who's writing that?
And why stop there? Why not abandon HTML 5's header element and WAI-ARIA's role="banner" when we implement a magical semantic guessing machine in every browser.
No point with headings, either! If a parser sees break elements surrounding some text that is wrapped by bold elements or a font element with a size that is larger than the computed size of the surrounding text, then it should assume that it's a heading and calculate, from surrounding text, what "level" of heading it is in the hierarchy.
To reformulate your sentence about aria roles on divs that are footers, "Its position in context coupled with the type of content makes clear it’s a heading."
Or, alternatively, we could not bloat browsers with programs that try to guess authorial intent on every view of every page, and instead provide a mechanism for authors to state their intent unambigously, just once. That could be - ooh, I don't know - perhaps an element in HTML 5 or a ARIA attribute that extends HTML 4?
_________________
www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum
International Lothario (retired)
Share:
| brucelawson wrote: |
|
Even if it is at the "bottom of the page", it may not be bottom of the source code, so your algorithm would presumably have to know how CSS has laid out the page to determine what's at the bottom of the page. It would probably need to wait to check that no scripts have inserted information, too. |
I believe you've hit the nail on the head with this one point Bruce. For good practice we separate out display and function from our sites. In such practice with accessibility (IMHO), the document should be able to stand independently from these layers and remain accessible. There is no role for derived accessibility except for last gasp. Also the levels of complexity that this would involve as well as the likelihood that it would just be plain wrong most of the time. The explicit declaration of intent within ARIA is placed at exactly the right layer, within the document.
I agree ARIA comes with an overhead that some may see as too large for the perceived benefits. This plainly will slow adoption, but as web authoring tools start to pick up on ARIA attributes this overhead will lessen.
Share:
" There is no role for derived accessibility except for last gasp." - I love that. An excellent maxim.
"I agree ARIA comes with an overhead that some may see as too large for the perceived benefits." - agree totally. ARIA isn't a magic bullet, and many authors won't adopt it. My head spins when I see some examples, as me and JavaScript are barely acquainted (though we once snogged at a party).
Stuart Langridge has an interesting proposal for another layer - an "ARIA stylesheet" (not to be confused with CSS): http://www.kryogenix.org/...
_________________
www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum
International Lothario (retired)
Share:
Footers
My article never suggests using AI to set a formal "this is a footer" semantic. I say there's no need for a formal semantic. I go on to explain how contentinfo is an inadequate semantic in the first place.
Well-made documents are usable without CSS. They will have the footer at the end of the source code. It's trivial to find that: go to the end of the document. For big footers, you then go up one block-level element at a time. It couldn't be any easier!
Headings
In contrast, there very much is a need for headings to use the formal semantics of <h1> to <h6>. During my research into headings I found you can't deduce headings reliably in the absence of heading elements.
- A short sentence by itself ending with a question mark, styled differently from the nearby runs of text, might be a heading:
- It might be an emphasised question.
- It might be an error; a slip of the mouse in a WYSIWYG editor.
- I've also seen the paragraph before a heading and the paragraph after have quite different styling, not just different markup.
- Sometimes whole paragraphs are big and bold to draw attention but are not headings.
- Sometimes headings are cased and even punctuated like sentences.
- Sometimes heading elements are misused to create such notices.
Presentationally-motivated markup is simply too irregular and illogical within and around each type of content to understand it mechanically. That's why it's a bad thing, remember?
Scope
| Bruce Lawson wrote: |
| Well, if you have some data that is about the whole site, then it is also about the parent document. |
Metadata
| Bruce Lawson wrote: |
| And why is a link to contact info not metadata about the site? |
HTML5
| Bruce Lawson wrote: |
| It strikes me that your argument is also an argument against the HTML 5 footer element. |
ARIA Stylesheets
In a word: yuck.
(EDIT) Corrected URLs.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Wow this is all new to me and very interesting.
I'm noticing more and more techniques to produce accessible sites/apps being made available. I wish I had the time to read them all and implement what I can.
The problem is I am not paid specifically to deploy accessibility. I'm paid to create RIA interfaces which is often VERY time consuming and usually I'm learning new things just to get by in that role.
"It's difficult to keep up with modern authoring techniques for RIA's never mind accessible ones!"
How many people on this forum are paid-up accessibility professionals? I think it's a good time for the accessibly groups to push for more specific roles rather than client side developers having accessibility put on them on top of what is already a difficult job.
Thats a bit of a rant sorry, I do really find this WAI RIA stuff very engaging and positive really.
_________________
Dan
Web Designer
www.colourpool.com
Share:
I thought ARIA was was only for JavaScript. Surely the additional tag attributes have no place in (x)HTML and will not be adopted by the majority of front end designers some of who struggle with basic accessibility, HTML and CSS (like what colourpool said)._________________
Johan De Silva / Portfolio | Place of Work @Flipside | Read my movie reviews punk!
Share:
| Johan007 wrote: |
| I thought ARIA was was only for JavaScript. |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Maybe I am just exhibiting a superiority complex._________________
Johan De Silva / Portfolio | Place of Work @Flipside | Read my movie reviews punk!
Share:
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum