Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Accessibility of the paging links in r5297 / r5292
From an accessibility POV, shouldn’t a list (ul and li) be used here to markup the paging block(s)? Right now, there is just a bunch of links separated by only white-space. It has always been my understanding that this is not helpful for AT. Using a list is still advised in the Accessibility Guidelines 2.0; see for example this page. Most references about this that I found in a quick $search-engine visit are quite old (2005-2006), but I think the recommendation still stands.
And note, one set is contains real links (prev-next) while the other set (pageby) contains links that behave as buttons. This might be confusing from an AT perspective.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Accessibility of the paging links in r5297 / r5292
Thanks Philippe
The code is relatively new so I’ve not had a really good look over it just yet – but be assured that I’ll make sure it’ll be as semantic and accessible as possible. Jukka has made it a list now and we’ve put some aria on the pageby to identify is as button toggles instead of links.
Offline
Re: Accessibility of the paging links in r5297 / r5292
Yeah, I saw that in r5302 and some fine tuning later. It is already a good improvement.
The pageby block is still just loose links inside a p however (although with@role=button@). Another issue I see affects small screen displays. The prev-next block is now very long and becomes a bit of a confusing clutter. I think one could reduce the number of links in the prev-next list to max. 5 (+ prev and next) without loss of functionality.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Accessibility of the paging links in r5297 / r5292
phiw13 wrote:
The pageby block is still just loose links inside a
phowever (although with@role=button@). Another issue I see affects small screen displays. The prev-next block is now very long and becomes a bit of a confusing clutter. I think one could reduce the number of links in the prev-next list to max. 5 (+ prev and next) without loss of functionality.
The pagination currently shows 5 links, plus the first/last pages when the pagination wouldn’t normally be able to show them.
Reducing that would mean loosing the jump links altogether which take 4 spots, or not listing any pages. The pagination needs to allow at least going to the first or last page from any page, to prev and next (so that you don’t have to change the element you need to click/tap) and to as many close by pages as possible. Ideally maybe even as many as you can fit to the screen using JavaScript.
Offline
Re: Accessibility of the paging links in r5297 / r5292
You could put a class name on the pagination number links so that they can be hidden a smallest breakpoint, leaving the prev/next links in place. That might work.
Offline
Re: Accessibility of the paging links in r5297 / r5292
Gocom wrote:
The pagination currently shows 5 links, plus the first/last pages when the pagination wouldn’t normally be able to show them.
Ok, thanks for explaining your reasoning behind the number of links. I’ll withdraw my kinda-objection then.
philwareham wrote:
You could put a class name …
Yeah, hiding the non-essential parts (everything except for prev and next links) is one of my ideas [*]. There are probably other options. I’ll have to talk to iPhone-girl – she actually manages a txp site on her device, I only spend time testing on those.
[*] e.g. like this
.nav-tertiary.prev-next > li:not(:first-child):not(:last-child) {
display: none;
}Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline