Accessibility of links

Accessibility of links

by Damyon Wiese -
Number of replies: 10

I recently tested an accessibility issue and found that the way we were addressing some accessibility issues did not match up with the WCAG recommendations. 

I have created a new issue for it (http://tracker.moodle.org/browse/MDL-39079) and wanted to raise this discussion in the forums. 

The summary is that I am seeing that some developers seem believe that adding a title attribute to a link provides more information for screen readers - but this does not seem to be the case.

<a href="..." title="View user profile">Bill</a>

is read with a screen reader as:

link Bill

and the title is ignored (If anyone could confirm/deny this behaviour in Jaws that would be awesome). 

It seems that the best way to do this (and support translations properly) is:

<a href="..."><span class="accesshide">View user profile for Bill</span><span class="accessshow">Bill</span></a>

http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/C7

I would like to confirm/clarify this approach in our dev docs and convert MDL-37079 into a meta for fixing our incorrect uses in core. 

I'm also hoping for lots of discussion from any accessibility experts who might be reading (or listening).

Average of ratings: -
In reply to Damyon Wiese

Re: Accessibility of links

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Well, your specific suggestion is bad. Duplicating Bill in the HTML is stupid.

If something like that is really necessary, then I would go for

<a href="...">Bill <span class="accesshide">(View user profile)</span></a>

(Also, I have no idea how you imagined class="accessshow" would be implemented in CSS.)

Even so, I don't think you are on the right lines. I htink your starting point ("developers seem believe that adding a title attribute to a link provides more information for screen readers") is an incorrect premise.

The main purpose of the title="" is to provide a tool-tip so people can discover more about the link before they click it.

  • That works nicely for mouse users on a traditional computer.
  • Not so good for tablets with touch screens.
  • Screen-readers? I don't know.

But really, what we are saying is this:

  • In the UI, as we first encouter at it, we want a nice clean UI with just the user's name (and perhaps a picture).
  • And then we feel that it is appropriate to provide a little extra information, to users who what it, to clarify that the link goes to that user's profile (rather than, say, to a picture of their pet cat I suppose).

Notice that those last two bullet points make no mention of which technology the user is using to interract with the UI - and if you can talk about the UI that way, then you are heading in the right directly to build something accessible.

So, for me, there are two questions

  1. Is the extra information really necessary? Isn't it obvious that in Moodle, a user's name always goes to their profile. (I just checked github. Their profile links are just the username.)
  2. If we feel extra information is necessary, is there something better than the HTML title attribute, which is designed for this purposes? It is then up to devices like tablets and screen-readers to correctly render that semantic HTML, or is I really necessary to workaround what we consider to be bugs in these devices handling of semantic HTML?
Average of ratings: -
In reply to Tim Hunt

Re: Accessibility of links

by Damyon Wiese -

Thanks Tim,

I don't really want to get bogged down over whether those specific links needed extra information or not (50/50) - the point is that there are links where extra information would be useful for users with screen readers and relying on the title tag to provide that information leads to a bad outcome. I would like to get some agreement on the best approach so we can add it to the dev docs and then apply it consistently.

Bill <span class="accesshide">(View user profile)</span>

Seems OK to me in english - I am not sure if it can be translated well or not.

If so - then great its a lot less strings and no need to invent some accessshow thing.

 

 

Average of ratings: -
In reply to Damyon Wiese

Re: Accessibility of links

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Right, do generate that HTML properly (from a translation piont of view) you need

$string['profilelink'] = '$a->name ($a->tip)';
$string['profilelinklinktip'] = 'View user profile';

and then put it together

get_string('profilelink', 'moodle', array('name' => fullname($user), 'tip' => html_writer::span(get_string('profilelinklinktip'), array('class' => 'accesshide'));

Average of ratings: -
In reply to Damyon Wiese

Re: Accessibility of links

by Jason Fowler -

Not all accessibility changes are made for screen readers operating on default browsers. There are accessibility addons that expand title attributes to make them readable for the screen readers. This is why the title attributes are being made more verbose.

Average of ratings: -
In reply to Jason Fowler

Re: Accessibility of links

by Damyon Wiese -

Jason, IMO this reasoning is 100% incorrect. 

Related article:

http://a11yproject.com/posts/title-attributes/

Summary (and WCAG agrees):

"There are a few times when using a title attribute is appropriate", 

"Rule of Thumb: Serve all users equal content"

Average of ratings: -
In reply to Damyon Wiese

Re: Accessibility of links

by Jason Hardin -

I think the point of that WCAG statement is that you shouldn't use title and access hide when the text would benefit everyone not just some one using a screen reader or just a sighted person.

The point of the mentioned ticket is that a user doesn't understand what Tim Hunt stated that the user's name when linked in Moodle always goes to their profile.

So to Tim's point Moodle is not like Github. A linked user's name doesn't always go to their profile. It can go to many different places based on where it is. Whether the user's name is at the site level, or the course level. Whether the user viewing the name is a teacher viewing a student's name or a student viewing their own name in an activity.

The reason for the ticket is that to be accessible links need to clearly tell the user where they will be going within the system if they click the link. Clicking Bob Smith in an interface doesn't really tell you that you will go to Bob Smith's profile. I would even argue that Github's use in not WCAG 2 compliant. Just because a well known product does something doesn't mean it is a good example of accessibility. It could be a good use or it could just be they haven't been sued over it. Educational institutions have legal requirements to be accessible that makes their accessibility compliance far greater than a company like Github.

Take bootstrap for example. It is used all over the web and has well known accessibility issues that Twitter has acknowledge as currently existing and having no resolution for.

Average of ratings: -
In reply to Jason Hardin

Re: Accessibility of links

by Damyon Wiese -

Agree that you shouldn't try and hide the text when it would benefit everyone - the user profile links are really a special case where showing the extra text is undesirable from an asthetic point of view. 

But the real point of this discussion is when a situation does arise and you want to provide more information to screenreaders for a link - what is the best approach to providing that information. Currently I am seeing title tags used to provide this extra information which according to WCAG is 100% wrong. WCAG says accesshide is the way to go (reposting link: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/C7).

 

Average of ratings: -
In reply to Damyon Wiese

Re: Accessibility of links

by Jason Hardin -

In that instance then i would go with Tim's suggestion only in the reverse. Make it read as a logical statement when read outloud. Bill (view user profile) doesn't make sense to me when I read it out loud. 

 

From a profile link stand point we maybe looking at this in the wrong direction. The ticket referenced says there are 2 links on the page with the user's name that go to different places. The other option here is to work towards the consistency of your links wihtin the interface. Consider a policy that says when the user's name is linked it should be linked to their profile, if it is not linked to their profile it should have accesshide information that tells the user where they are going.

For instance a grade table I click on the user and go to the user's list of grade.  This link would be <accesshide>View all of </accesshide>(student's name)<accesshide>'s grades.</accesshide>.

To me the answer is be consistent in where the links goes when text is used, and I would agree with Damyon that WCAG says to add accesshide if more information is required to tell the user where the link is sending them.

Average of ratings: -
In reply to Jason Hardin

Re: Accessibility of links

by Damyon Wiese -

The problem with this example Jason is it is a nightmare for translators to create a language string broken up like that. 

 

 

Average of ratings: -
In reply to Damyon Wiese

Re: Accessibility of links

by Stuart Lamour -
Picture of Plugin developers

every internet user expects a link with someones full name in e.g.

Carl Sagan 

to be a link to more info about the text within the link - title or no title.

people using screen readers are exactly the same.

you don't need to add a title, hide special text of any of that other gubbins. no one else does.

My advice Damyon is to go find some of your users with a screen reader and watch them using the internet.

In our experience adding extra cruf just gets in their way. 

Be sure and post what you find out.

Average of ratings: -