[patch] WAI ARIA landmark roles for improved accessibility in beez template
Peter Krantz
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=15783
The WAI ARIA specification defines a set of specialised "landmark"
roles. These roles provide a method to programmatically identify commonly found
sections of web page content in a consistent way. This allows assistive
technologies (e.g. a screen reader) to provide users with features which they
can use to identify and navigate to sections of page content.
Landmark roles are specified with the role attribute in HTML. In order to keep
the template markup valid (when testing with the W3C markup validation service)
this patch adds landmark role data with a small javascript after the page has
loaded.
The patch adds landmark roles for navigation, main, complementary, contentinfo
and banner to the beez template included with Joomla 1.6.
For more information on WAI-ARIA landmark roles see:
Using WAI ARIA landmark roles by Steve Faulkner:
http://www.paciellogroup.com/blog/?p=106
and the WAI-ARIA specification.
http://www.w3.org/WAI/PF/aria/
Regards,
Peter Krantz
Hannes Papenberg
thanks for this patch. Commited it to trunk. :-)
Hannes
Peter Krantz schrieb:
Peter Krantz
will have a look at it and start working with accessibility in their
templates. Maybe there is a template guideline page that could include
some advice?
Regards,
Peter
pollen8
>the template markup valid (when testing with the W3C markup validation service)
>this patch adds landmark role data with a small javascript after the page has
>loaded.
cheers
Rob
Peter Krantz
>
> silly question but do screen readers these days process javascript?
>
Not a silly question, I am glad you asked. A screen reader typically
works on top of a browser (e.g. IE or Firefox) and gets access to the
DOM which may have been manipulated with javascript. WAI-ARIA defines
a number of standardized interaction properties that can give a screen
reader more details what e.g. a <div> is about (it may masquerade as a
complicated button with script).
So, yes, a screen reader will typically work with script, but without
more information it may be difficult to know if a region has been
dynamically updated while doing something else in the page. This is
what WAI-ARIA tries to solve.
Regards,
Peter
Niels Braczek
> The WAI ARIA specification defines a set of specialised "landmark"
> roles. ... the WAI-ARIA specification.
> http://www.w3.org/WAI/PF/aria/
Erm... "This is an Editor's Draft of the Protocols and Formats Working
Group. It is not stable and may change at any time. Implementors should
not use this for anything other than experimental implementations."
I hope it is de-activated by default.
Regards,
Niels
Peter Krantz
>
> Erm... "This is an Editor's Draft of the Protocols and Formats Working
> Group. It is not stable and may change at any time. Implementors should
> not use this for anything other than experimental implementations."
>
That is the standard W3C text for all documents that haven't moved to
the final step of the recommendation chain.
However, ARIA landmark roles have already been implemented in
assistive technology (e.g. the JAWS screen reader) and browser
developers have already implemented other parts of the ARIA spec
(notably IE, Firefox and Opera).
Without more live implementations assistive technology manufacturers
will take a long time to add support. With more live examples users
will get the benefits faster.
The landmark roles appear to be stable and adding them with a script
will not affect other users at all.
Regards,
Peter
Niels Braczek
> However, ARIA landmark roles have already been implemented in
> assistive technology (e.g. the JAWS screen reader) and browser
> developers have already implemented other parts of the ARIA spec
> (notably IE, Firefox and Opera).
Ok then.
> Without more live implementations assistive technology manufacturers
> will take a long time to add support. With more live examples users
> will get the benefits faster.
Good point.
Regards,
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Rimas Kudelis
2009.04.04 08:32, Peter Krantz wrote:
> Tracker item:
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=15783
>
> The WAI ARIA specification defines a set of specialised "landmark"
> roles. These roles provide a method to programmatically identify commonly found
> sections of web page content in a consistent way. This allows assistive
> technologies (e.g. a screen reader) to provide users with features which they
> can use to identify and navigate to sections of page content.
>
That's great!
> Landmark roles are specified with the role attribute in HTML. In order to keep
> the template markup valid (when testing with the W3C markup validation service)
> this patch adds landmark role data with a small javascript after the page has
> loaded.
>
Hm, I'm not sure that obscuring properties that are invalid by adding
them via JavaScript is the right way. Because what I think you do is
basically invalidate DOM in any JS-capable UA, and it's only a
coincidence (though reasonable) that validators are not such.
For example, here's an excerpt from the HTML5 specification (which is
also in Editor's Draft state right now), section 2.2 [1]:
> Conformance checkers must check that the input document conforms when
> parsed without a browsing context (meaning that no scripts are run,
> and that the parser's scripting flag is disabled), and should also
> check that the input document conforms when parsed with a browsing
> context in which scripts execute, and that the scripts never cause
> non-conforming states to occur other than transiently during script
> execution itself. (This is only a "SHOULD" and not a "MUST"
> requirement because it has been proven to be impossible. [HALTINGPROBLEM])
While Beez is (most probably) not an HTML5 or XHTML5 template, I think
such criteria to what is and what's not valid could and should be
applied to any other version of HTML or XHTML, and from what I've found
so far, XHTML Role Attribute Module [2] (part of XHTML2, if I get it
correctly) is the only place that defines the role attribute.
My point here is that I really doubt it's worth to employ JS to add the
role property. I think in this case, you basically have to choose
between standards-compliance and accessible markup, and if you choose
the latter, employing JS just for the sake of pleasing validator by
exploiting its incompleteness doesn't necessarily look attractive. Of
course, current solution would please many users of Beez who happen to
test their website for validity, but it doesn't make the document any
more valid.
I also suspect that the syntax described in Paciello Group Blog [3] is
not necessarily finalized. On the other side, in the comments for their
other post [4], Ian Hickson has stated he has plans to introduce ARIA in
HTML5 in April this year, so, maybe it's worth to wait until then?
Because even if Beez isn't going to switch to XHTML5, there would at
least be an agreement on how ARIA properties are supposed to be used in
this language, so Beez could employ the same scheme. OTOH,
standardization of these properties could probably be tempting enough to
consider converting to that XHTML5 (or maybe its subset without the new
tags).
Regards,
RQ
[1] http://dev.w3.org/html5/spec/Overview.html#conformance-requirements
[2] http://www.w3.org/TR/2007/WD-xhtml-role-20071004/
[3] http://www.paciellogroup.com/blog/?p=106
[4] http://www.paciellogroup.com/blog/?p=107#comment-6517
Peter Krantz
>
> Hm, I'm not sure that obscuring properties that are invalid by adding
> them via JavaScript is the right way. Because what I think you do is
> basically invalidate DOM in any JS-capable UA, and it's only a
> coincidence (though reasonable) that validators are not such.
>
The W3C working group recommends that ARIA is implemented now [1] as
UAs are already implementing support for it. The WG also seem to be
developing enhanced DTD:s to cope with validation of ARIA attributes
in markup. The WAI-ARIA primer also mentions HTML 4 explicitly [2].
Waiting for HTML5 is not an option. That would mean WAI-ARIA
accessibility features won't benefit end users until after 2012 (Btw,
the HTML5 WG also recommends implementing HTML5 as soon as browsers
start supporting it).
[1]: http://www.w3.org/WAI/aria/faq.html#do_now
[2]: http://www.w3.org/TR/wai-aria-primer/#ariahtml
Regards,
Peter
Andrew Eddie
new core layouts (Beez becomes redundant then)? The intention is to
make the core frontend output clean and semantic.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/4/4 Hannes Papenberg <hack...@googlemail.com>:
Hannes Papenberg
classes are not what I would expect from the Joomla core. In the end,
its not the worst to look over this and doing this properly with all the
knowledgeable people involved. Amy wanted to contact the necessary
people for this, among them the Joomlatworks people and Angie Radtke.
Hannes
Andrew Eddie schrieb:
Rimas Kudelis
However, you completely overlooked the main point of my letter. The point is that your solution uses JavaScript to basically invalidate the document (which is still supposed to conform to its DTD, isn't it?) just because the validator leaves such things uncaught because it doesn't process Javascript. While this looks attractive and would surely please anyone looking at the validator output, on the other hand I think it can be considered as both bad and inaccessible (sic!) practice:
* It's bad because this way you can write anything and call it e.g. "valid XHTML1.1" while in the reality it would not be. How? Just create a valid XHTML1.1 document with an empty body, and use Javascript to set its innerHTML to whatever invalid markup you like. The validator will never complain, but does that make the resulting document a valid one? I seriously doubt.
* It's inaccessible because it wouldn't work with JS disabled, and why would such accessibility features have to ever depend on JS?
So, my suggestion is to just follow the examples at WIA-ARIA Primer, which you have referenced, and specify roles inline. This would clearly indicate that Beez puts accessibility above DTD conformance, and would not hide the fact that the template is actually not conformant (unless of course I'm wrong about the latter). And if/when the WAI-PF WG would create enhanced DTD's, Beez could investigate the opportunity to just switch to them.
Rimas
Peter Krantz
>
> However, you completely overlooked the main point of my letter. The point is
> that your solution uses JavaScript to basically invalidate the document
> (which is still supposed to conform to its DTD, isn't it?) just because the
> validator leaves such things uncaught because it doesn't process Javascript.
Yes I know, but I was trying to be pragmatic. If you add the role
attributes to the markup itself (which is the best option) my
experience says that there are a lot of people who will be reluctant
to use the theme (because all they know is that things have to
"validate"). Then there would be no point in making the change.
> * It's bad because this way you can write anything and call it e.g. "valid
> XHTML1.1" while in the reality it would not be. How? Just create a valid
> XHTML1.1 document with an empty body, and use Javascript to set its
> innerHTML to whatever invalid markup you like. The validator will never
> complain, but does that make the resulting document a valid one? I seriously
> doubt.
You are taking things to the extreme. I understand the principle. My
patch will give you a DOM with unknown attributes on a few nodes that
some browsers will ignore but with a potential benefit to ther users.
How does this specific patch matter in practice?
I take accessibility over a valid DOM every day.
> * It's inaccessible because it wouldn't work with JS disabled, and why would
> such accessibility features have to ever depend on JS?
>
I agree, but see answer above. You need to make sure the templates are
used as well.
> So, my suggestion is to just follow the examples at WIA-ARIA Primer, which
> you have referenced, and specify roles inline. This would clearly indicate
> that Beez puts accessibility above DTD conformance, and would not hide the
> fact that the template is actually not conformant (unless of course I'm
> wrong about the latter).
I would be happy to contribute a patch for this as well, but would
people use the beez template then? Without people actually using it we
would have gained nothing (apart from some developers reading this
interesting discussion and starting to learn more about WAI-ARIA of
course :-)
Regards,
Peter
Rimas Kudelis
On Sun, Apr 5, 2009 at 00:37, Rimas Kudelis <r...@rq.lt> wrote:However, you completely overlooked the main point of my letter. The point is that your solution uses JavaScript to basically invalidate the document (which is still supposed to conform to its DTD, isn't it?) just because the validator leaves such things uncaught because it doesn't process Javascript.Yes I know, but I was trying to be pragmatic. If you add the role attributes to the markup itself (which is the best option) my experience says that there are a lot of people who will be reluctant to use the theme (because all they know is that things have to "validate"). Then there would be no point in making the change.
Rimas
Peter Krantz
>
> OK, you're right. :) Thanks for your patience. :)
>
Thank you for asking the questions. I hope this thread can be useful
to other people that are thinking about validation, javascript,
WAI-ARIA and the DOM.
Regards,
Peter