[accessibility] prev/next links and their arrows

phiw13 · 2014-11-03 14:02:02

Can those arrows be wrapped inside a span aria-hidden=true ?
(the eventual problem is that those arrows are included in the language file(s) — but I think that those file support markup as well).

VoiceOver and most other screenreaders will, AFAICT, speak these arrows by their Unicode name (LEFTWARDS ARROW, RIGHTWARDS ARROW) followed by the word “prev” or preceded by “next”; that is a bit (ahem) disturbing to the user, me thinks. This particular symbol wouldn’t be so dramatically bad, for the English user. For the non-English user, it would be really annoying (there is no localised unicode name).

—
Related: the string/word ”prev” isn’t immediately great either, from a screenreader perspective.

Bloke · 2014-11-03 14:25:01

phiw13 wrote #285414:

Can those arrows be wrapped inside a span aria-hidden=true ?

Yes in theory. This is the slight downside to moving the entire label to a Textpack. It’s “right” from a l10n standpoint (and helps with RTL languages) but it does mean we have to add markup to the Textpack strings to circumvent issues like this, which is slightly annoying. EDIT: forgot to say it may not be a trivial change. Including markup in the strings means we need to inform Textpattern of this fact when rendering such strings, otherwise it html-encodes any markup.

One way round it would be to get rid of the arrows altogether on the buttons. Do they serve any visual purpose, given the wording is also present? Maybe they offer a little clue as to which direction things go without having to read the label itself, but would it be a great loss to have just words? I don’t know. Or maybe lose the words and just use a glyph, if there is such a glyph that is read universally by screen readers…?

If going with text, using the full word ‘Previous’ gets my vote. But that means the buttons won’t be the same size which might jar with the visuals or require extra markup to ensure labels in all languages fit within some arbitrarily-defined maximum width.

Mr. Wareham, over to you :-)

Last edited by Bloke (2014-11-03 14:28:42)

phiw13 · 2014-11-03 14:41:35

Bloke wrote #285416:

EDIT: forgot to say it may not be a trivial change. Including markup in the strings means we need to inform Textpattern of this fact when rendering such strings, otherwise it html-encodes any markup.

I was afraid of that…

One way round it would be to get rid of the arrows altogether on the buttons. Do they serve any visual purpose, given the wording is also present? Maybe they offer a little clue as to which direction things go without having to read the label itself, but would it be a great loss to have just words? I don’t know. Or maybe lose the words and just use a glyph, if there is such a glyph that is read universally by screen readers…?

Personally, as a user, they annoy me more than anything…
There is no glyph that would be understandable to screenreader users – or rather that really represents the concept “previous page” etc; but a bit of CSS generated content can go a long way – hiding the text string and only displaying an arrow (without using a glyph, again, accessibility issue – use a SVG background image).

That would leave the responsibility & the choice (!) to the theme author. A bonus.

If going with text, using the full word ‘Previous’ gets my vote. But that means the buttons won’t be the same size which might jar with the visuals or require extra markup to ensure labels in all languages fit within some arbitrarily-defined maximum width.

Isn’t that already a problem for some languages? (and Yes from me for the full word, btw)

michaelkpate · 2014-11-03 14:47:53

phiw13 wrote #285418:

That would leave the responsibility & the choice (!) to the theme author. A bonus.

Anything that gives more control to the user (without breaking fundamental functionality) I am in favor of.

Bloke · 2014-11-03 15:13:35

phiw13 wrote #285418:

That would leave the responsibility & the choice (!) to the theme author.

Yes, that’s where it should be. Or at least with the person who sets up the language pack. As long as we tell Textpattern to interpret those strings as ‘raw’, people can put whatever markup they like in there. It may already be set up that way, I’d have to check the code.

Isn’t [fitting text within some arbitrarily-defined maximum width] already a problem for some languages?

If the button isn’t set to fit the content, yeah. I’m all for letting widgets grow to accommodate anything they contain, but at some point this becomes difficult, as you no doubt know being a theme author. This is especially true if you have a long word on a button and the user has chosen 500% zoom level.

I don’t know if the buttons are set to a fixed width or not. The current CSS file is just impenetrable to tiny minds like mine and seems to prescribe rules to the micro level, presumably to improve the experience across devices and browsers. My CSS approach tends to be “enforce the minimum possible, let the browser do the rest and if it looks halfway decent, it’s a result.”

Given the huge amount of specific rules and overrides in use in Textpattern’s stylesheets, I fear I may be massively out of touch with the real multi-device web :-)

philwareham · 2014-11-03 18:51:38

Leave it with me, I’ll take ownership of this one.

philwareham · 2014-11-03 21:27:50

OK been looking at this, do we even need previous/next article links on the write page? How much value does that really have?

On list pages, previous and next buttons are used to move between pages in a paginated list, but the UX is pretty shit really. Probably should use « ‹ › » buttons there along with aria-label so screenreaders get a spoken description, in my opinion. Previous and Next text is too fluffy (say you’ve come back from page 3 to page 2 and the click the ‘Previous’ link it’ll take you to page 1 when your previous page was page 3, for example).

What to do?

philwareham · 2014-11-03 21:58:24

How about this, for example?…

<ul class="nav-tertiary prev-next">
    <li><span class="navlink-disabled" aria-disabled="true" aria-label="Go to the first page">«</span></li>
    <li><span class="navlink-disabled" aria-disabled="true" aria-label="Go to the previous page">‹</span></li>
    <li><a class="navlink-active" href="#">1</a></li>
    <li><a class="navlink" href="#">2</a></li>
    <li><a class="navlink" href="#">3</a></li>
    <li><a class="navlink" rel="next" href="#" title="Go to the next page" aria-label="Go to the next page">›</a></li>
    <li><a class="navlink" href="#" title="Go to the last page" aria-label="Go to the last page">»</a></li>
</ul>

Is that an improvement?

jakob · 2014-11-03 22:25:19

OK been looking at this, do we even need previous/next article links on the write page? How much value does that really have?

On already written articles, I do use the next/prev buttons in the write pane to step back and forth between neighbouring articles, especially when the share similar details in custom fields or when adjusting posted dates to get the right display order etc.

Otherwise, your pagination code looks good to me.

phiw13 · 2014-11-03 23:15:47

philwareham wrote #285422:

OK been looking at this, do we even need previous/next article links on the write page? How much value does that really have?

That is a good question. It does add a bit of ‘noise’ to an already noisy UI. Personally I very rarely use them… (say, switch between 2 articles that are in each other immediate neighbourhood). As an editor I would use it more it this ‘previous/next article’ widget could reflect a filtered list on the article listings page: for example, if I filter the articles list by a set of criteria, click on one article, edit, the previous/next buttons on the write pane could reflect that filtered list…)

phiw13 · 2014-11-03 23:27:33

philwareham wrote #285423:

How about this, for example?…

[snip code]

That would certainly be an improvement and gives greater flexibility to theme authors to style those links as they feel, as the markup contains an accessible (and localisable) string.

philwareham · 2014-11-04 08:25:03

Ok Stef, let’s work that into the admin-layout-update branch on GitHub. Regarding the article edit screen prev/next – I’d vote to remove them. If people need them there could be a plugin to reintroduce them.

Textpattern CMS

Textpattern CMS support forum

#1 2014-11-03 14:02:02