18 May
2010
18 May
'10
7:29 p.m.
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
24 May
24 May
3:51 p.m.
New subject: [xwiki-devs] [VOTE] Improve accessibility of livetables pagination
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/
25 May
25 May
10:26 a.m.
New subject: [xwiki-devs] [VOTE] Improve accessibility of livetables pagination
On Mon, May 24, 2010 at 15:51, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 05/18/2010 07:29 PM, Denis Gervalle wrote:
<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
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/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
11:35 a.m.
New subject: [xwiki-devs] [VOTE] Improve accessibility of livetables pagination
On 05/25/2010 10:26 AM, Denis Gervalle wrote:
On Mon, May 24, 2010 at 15:51, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
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.
On 05/18/2010 07:29 PM, Denis Gervalle wrote:
<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). 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?
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/
12:17 p.m.
New subject: [xwiki-devs] [VOTE] Improve accessibility of livetables pagination
On Tue, May 25, 2010 at 11:35, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On 05/25/2010 10:26 AM, Denis Gervalle wrote:
<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.
On Mon, May 24, 2010 at 15:51, Sergiu
Dumitriu<sergiu(a)xwiki.com> 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?
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.
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.
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5228
days inactive
5235
days old
4 comments
2 participants
participants (2)
-
Denis Gervalle -
Sergiu Dumitriu