[xwiki-devs] [VOTE] Improve accessibility of livetables pagination
Hi devs, Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use <span> for numbers, and also use empty <span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled. I attach a patch that improve the situation by using <a> in place of <span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged. Here is my +1 to apply this ASAP on trunk. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On 05/18/2010 07:29 PM, Denis Gervalle wrote:
Hi devs,
Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use<span> for numbers, and also use empty<span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled.
I attach a patch that improve the situation by using<a> in place of<span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged.
Here is my +1 to apply this ASAP on trunk.
+1, with one remark: why do you use href="#", and not just not use href at all? -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mon, May 24, 2010 at 15:51, Sergiu Dumitriu <[email protected]> wrote:
On 05/18/2010 07:29 PM, Denis Gervalle wrote:
Hi devs,
Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use<span> for numbers, and also use empty<span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled.
I attach a patch that improve the situation by using<a> in place of<span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged.
Here is my +1 to apply this ASAP on trunk.
+1, with one remark: why do you use href="#", and not just not use href at all?
<a> without href is not considered as a link by most browsers. An <a> without attribute is just like a span ! Even the a:hover style is not applied on some of them (at least webkit based do not). Since my goal is to provide real links so the navigator or the assistive reader report them as links properly without css, it is require to put an href, else my changes are just useless. Note that the HTML specification says that you may create <a> without href (and without id/name), but only to setup them later through scripts. Be aware that some browser dislike that and never change the <a> to a link when the script add the attribute. So, my advice and now good habits is to always put an href="#" on any links that are resolve programmatically. Also note that if the event is processed (not stopped as we do here), these links could create entries in the history of the browser. Denis
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On 05/25/2010 10:26 AM, Denis Gervalle wrote:
On Mon, May 24, 2010 at 15:51, Sergiu Dumitriu<[email protected]> wrote:
On 05/18/2010 07:29 PM, Denis Gervalle wrote:
Hi devs,
Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use<span> for numbers, and also use empty<span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled.
I attach a patch that improve the situation by using<a> in place of<span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged.
Here is my +1 to apply this ASAP on trunk.
+1, with one remark: why do you use href="#", and not just not use href at all?
<a> without href is not considered as a link by most browsers. An<a> without attribute is just like a span ! Even the a:hover style is not applied on some of them (at least webkit based do not).
a:hover should be applied no matter if there's a href or not. What does not get applied is a:link:hover, which is normal, since it's not a link. If it doesn't point anywhere, then it isn't a link. Making it pretend that it is a real link is not much better than using a generic span.
Since my goal is to provide real links so the navigator or the assistive reader report them as links properly without css, it is require to put an href, else my changes are just useless.
Why not use ARIA roles? http://www.w3.org/TR/wai-aria/roles#link Using ARIA is even better, since it allows to specify other properties as well: aria-controls, aria-disabled, aria-busy, aria-label, aria-live.
Note that the HTML specification says that you may create<a> without href (and without id/name), but only to setup them later through scripts. Be aware that some browser dislike that and never change the<a> to a link when the script add the attribute.
But we're not changing the href at all. Another option would be to also change the href to point to the proper fragment when serialization is enabled.
So, my advice and now good habits is to always put an href="#" on any links that are resolve programmatically. Also note that if the event is processed (not stopped as we do here), these links could create entries in the history of the browser.
Denis
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Tue, May 25, 2010 at 11:35, Sergiu Dumitriu <[email protected]> wrote:
On 05/25/2010 10:26 AM, Denis Gervalle wrote:
On Mon, May 24, 2010 at 15:51, Sergiu Dumitriu<[email protected]> wrote:
On 05/18/2010 07:29 PM, Denis Gervalle wrote:
Hi devs,
Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use<span> for numbers, and also use empty<span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled.
I attach a patch that improve the situation by using<a> in place of<span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged.
Here is my +1 to apply this ASAP on trunk.
+1, with one remark: why do you use href="#", and not just not use href at all?
<a> without href is not considered as a link by most browsers. An<a> without attribute is just like a span ! Even the a:hover style is not applied on some of them (at least webkit based do not).
a:hover should be applied no matter if there's a href or not. What does not get applied is a:link:hover, which is normal, since it's not a link.
a:hover does not get applied. You may see this as an issue in webkit, but it is.
If it doesn't point anywhere, then it isn't a link. Making it pretend that it is a real link is not much better than using a generic span.
Since my goal is to provide real links so the navigator or the assistive reader report them as links properly without css, it is require to put an href, else my changes are just useless.
Why not use ARIA roles? http://www.w3.org/TR/wai-aria/roles#link
We could, this could be nice, but since we do not anywhere currently, I would see this as a larger patch that consider the whole UI.
Using ARIA is even better, since it allows to specify other properties as well: aria-controls, aria-disabled, aria-busy, aria-label, aria-live.
Yes, but you should also consider that ARIA is still quite recent. I have worked on several project for disabled people, and meet blind people that stay with IE6 and an old reader since assistive readers are expensive. I doubt that such reader knows anything about ARIA. So, sometime, keeping things simple is better. As a general rules, I avoid using <div> or <span> when there is more meaningful tag for the goal of my markup. <div> and <span> are good for cases when you cannot do without.
Note that the HTML specification says that you may create<a> without href (and without id/name), but only to setup them later through scripts. Be aware that some browser dislike that and never change the<a> to a link when the script add the attribute.
But we're not changing the href at all. Another option would be to also change the href to point to the proper fragment when serialization is enabled.
Yes, I am just referring to the specification here, I do not see any reason to do so here, since the permalinks information is in the hash and could only be used by local javascript. So what would be the advantage? I do not think putting these changes in the browser history would be an improvement, but this is the only advantage it could provide IMO. I have committed my patch in r28991 based on XWIKI-5219. We could always improve further later. Denis
So, my advice and now good habits is to always put an href="#" on any links that are resolve programmatically. Also note that if the event is processed (not stopped as we do here), these links could create entries in the history of the browser.
Denis
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (2)
-
Denis Gervalle -
Sergiu Dumitriu