Proposal - optional role / attributes for <a> to programmatically determine if it is a 'call to action' to a screenreader user

[mathalete]

For a sighted user, a visually prominent 'call to action' hyperlink in a document is normally created following the principle of Fitts' law (ie: targets that are larger and closer to the pointing device are easier to hit than ones that are smaller and further away).

Large, colourful with enticing text, it's pretty clear to a sighted user what the primary call to action on a page would be.

There is no equivalent of a call to action link for a screen reader user, as all links are given equal weighting in a rotor (VoiceOver) or list view (JAWS / NVDA).

In usability studies with screenreader users I've observed in documents with lots of links it can be difficult for users to find what the call to action is (for reference, there's a similar thread on a webaim mailing list).

Current options to try and do this could include...

<a href="foo.html" aria-label="Buy now (primary call to action)">Buy now</a>
<a href="foo.html">Buy now <span class="visuallyhidden">(Primary call to action)</span></a>

or

<a href="foo.html" aria-roledescription="primary call to action">Buy now</a>

However, if we go back to think about Fitts' law in an analogous way, any of these methods isn't changing the findability of the link, just the computed text value.

Ideally a call to action link should be very clear at the top of the links list of the screenreader, or maybe displayed in the document landmarks list... and I appreciate that's a different matter to the aria-spec.

In the interests of trying to provide an equivalent user experience, perhaps adding an attribute to the native <a> could work, or maybe use of WAI-ARIA could plug a semantic gap where HTML cannot facilitate.

I'd like to propose that a role could be applied to a hyperlink to allow it to programmatically determinable if it is a call to action in document.

Maybe a little bit like this.

Primary:

<a href="tickets.html" role="calltoaction" aria-level="1">Buy tickets</a>
Secondary:

<a href="contact.html" role="calltoaction" aria-level="2">Contact</a>

Thoughts?

[mcking65]

One way to address this in the page design is to put the call to action at the beginning of the main content.

However, I do agree that an attribute could potentially be useful if assistive technologies were smart about what they did with it.

This is very similar to the idea that we should be able to identify a primary or default button in a dialog. We had an issue for that, and I recalled us assigning it to ARIA 2.0.
What is really odd though, is that I now see only 6 issues coming up with the ARIA 2.0 label.

@jnurthen, at one time, I recall the primary button issue being assigned to you. Do you remember what happened to it or can you find it?

[mathalete]

A 'call to action' is just an example, but my opinion is that there definitely needs be a means to specify the relative importance of a hyperlink to other hyperlinks in the context of the document.

Ideally then an assistive technology should provide a means for a user to filter that important content to the fore to improve the findability of key page elements.

[jnurthen]

There is https://www.w3.org/WAI/ARIA/track/issues/624

…

On Tue, 18 Apr 2017 at 00:39 Peter H ***@***.***> wrote: A 'call to action' is just an example, but my opinion is that there definitely needs be a means to specify the relative importance of a hyperlink to other hyperlinks in the context of the document. Ideally then an assistive technology should provide a means for a user to filter that important content to the fore to improve the findability of key page elements. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#559 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpQPx26H-Ic-PYqh26sKfmnMoP9rxYBks5rxGiugaJpZM4M-mIs> .

[mathalete]

Perhaps what we have at present is suffice on the proviso that the author chooses an appropriate nomenclature.

Example

 <div role="region" aria-roledescription="Primary action" aria-labelledby="primarycalltoaction">
    <a id="primarycalltoaction" href="#">Contact us</a>
  </div>

[jnurthen]

I wouldn't want each call to action to be a landmark.

…

On Thu, 27 Apr 2017 at 11:06 Peter H ***@***.***> wrote: Perhaps what we have at present is suffice on the proviso that the author chooses an appropriate nomenclature. Example <div role="region" aria-roledescription="Primary action" aria-labelledby="primarycalltoaction"> <a id="primarycalltoaction" href="#">Contact us</a> </div> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#559 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpQP1wLAdi4dVyakTGHpLHkxyhNwyiDks5r0NkjgaJpZM4M-mIs> .

[mathalete]

I agree, the more calls to action you'd add the less meaningful each would become, and author discretion is clearly advised.

I would expect only the primary and possibly the secondary important link in the document could be shown in a similar way to how a role=region is shown in the VoiceOver rotor (MacOS) - which could improve the findability of designated links.

[mcking65]

@mathalete commented:

I would expect only the primary and possibly the secondary important link in the document could be shown in a similar way to how a role=region is shown in the VoiceOver rotor (MacOS) - which could improve the findability of designated links.

As a screen reader user who uses Mac quite a bit, I don't understand this point. It is extremely unlikely that screen reader users will discover a call to action via the rotor. The rotor is primarily for circumstances where you know what kind of thing/content you want to navigate to. In general, I am not aware of people using it as a primary discovery mechanism.

In visual design, my understanding is that a call to action is something that stands out. It is attention grabbing. Ensuring something is reachable with the rotor does not have this effect.

Thus, if my understanding is correct, the design goal is prominence.

IN today's world, I am pretty sure the most effective way to achieve this objective for users who rely on sequential perception is to make the call to action one of the first elements in the main content. I am somewhat doubtful that an attribute will help unless we think that screen reader developers would be likely to do something very special with it.

[mathalete]

Thanks Matt, it's always interesting to hear your thoughts.

I am sighted, and I use screenreaders for testing.

I have been in usability studies with screenreader users and my suggestion is based on observations and conversations arising from those studies.

As a screen reader user who uses Mac quite a bit, I don't understand this point.

Sorry, please excuse any lack of clarity on my part.

It is extremely unlikely that screen reader users will discover a call to action via the rotor. The rotor is primarily for circumstances where you know what kind of thing/content you want to navigate to.

I do understand what the rotor (or the lists of elements features in JAWS or NVDA) is for.

Screen reader users will sometimes obtain an alphabetically-organised list of links, or a list in the order of which the links appear in the document.

Both using the rotor and in navigating sequentially through a document, each link will have the same priority / prominence.

In visual design, some links are given more aesthetic prominence over others, my suggestion is based from conversations with screenreader users that having some hierarchy to links would be desirable.

As far as I am aware, ARIA doesn't have a means to indicate priority for links. The closest we would have would be the aria-level attribute which is used for defining a heading structure or the level of a list item within a list.

My example with using the rotor was simply intended to show one possible way to bring important content to the fore.

My example is a fudge to see if the prominence or findability of a link can be improved with what we have with aria at the moment, when both navigating sequentially or using the rotor.

I do think having means to define granularity to the relative importance of content in the context of the document would be useful in some use cases for sure - a call to action hyperlink is just an example of this.

I am somewhat doubtful that an attribute will help unless we think that screen reader developers would be likely to do something very special with it.

I understood this is the case with any aria attributes?

Yes, screenreader developers should really work out how they want to best expose content with prominence attributes - examples could include, a rotor setting, an announcement, whatever to say "show me all elements with the important attribute".

IN today's world, I am pretty sure the most effective way to achieve this objective for users who rely on sequential perception is to make the call to action one of the first elements in the main content.

I hear what you're saying, and yes, context and having content in a logical and intuitive order can be really helpful, however I'm not confident that developers will always do this.

[Wildebrew]

As a blind user and an accessibility professional, I think an aria-primary attribute would be extremely useful.

It is difficult to move primary call to action links in the DOM.
A link needs to fit into the content flow of the page, and often the primary action on a webpage needs an introduction. If we move the link to the top of the content we either force content people to rephrase the content on the page significantly (and often less effectively), or we alter the reading / content order of the page and run the risk of introducing reading order issues.

A screen reader should simply indicate the primary link with the word "primary" or "prominent", or read the primary link in a slightly higher pitch. Optionally, a screen reader could implement a mechanism to let users display primary links at the top of a list of links.

I think a single attribute, such as aria-important that takes values such as "primary" or "secondary", or a Boolean aria-isprmary attribute would do the trick.
I think aria-current is the second most useful attribute of ARIA 1.1 (after aria-modal, when it has more a.t. support).
An aria-primary would fal in the same category, an attribute that enables webpage authors to communicate information programmatically to assistive technologies that is currently only available through visual styling or through inconsistent use of off-screen text.

[patrickhlauke]

cross-referencing this https://discourse.wicg.io/t/proposal-optional-role-for-a-to-indicate-if-it-is-a-call-to-action-to-a-screenreader-user/2119/7

[ZoeBijl]

There is https://www.w3.org/WAI/ARIA/track/issues/624

@jnurthen you still have the draft you worked on? That issue is on me but I remember you wrote something and said you were gonna do something with that.

[jnurthen]

@ZoeBijl Sorry it took me 2 years to reply :)
I did find this in the archives
https://lists.w3.org/Archives/Public/public-aria/2015Dec/0047.html

[mathalete]

Thanks @jnurthen - it took me 3 months to read this : )

'aria-primaryaction' is exactly what I was proposing - great minds etc.

[patrickhlauke]

what if it's a secondary action, but still important?

[jnurthen]

@patrickhlauke then it is still a button and can still be activated.
Looking through a number of design systems (Adobe,Google,Microsoft,US Gov, Gov.uk) I found the following button types in more than 1 of the design systems.
Call to Action (other terms: contained, primary, brand, "big button", default/start button)
Standard (other terms: primary, outlined, standard, neutral, default, secondary)
Secondary (other terms: text, base, secondary)
Negative (other terms: destructive, warning)

We could consider an attribute which allows these other types to be specified too (although tbh I'm not sure I see the need to distinguish standard from secondary - but the negative/desctructive case seems potentially useful)

[patrickhlauke]

i'm probably cheekily playing devil's advocate here, but my concern is about having an attribute name that is TOO specific and potentially then ending up with something that's not a good fit (isprimary may imply uniqueness ... the one and only primary control, rather than "one of a few primary controls"). also, why the "is" prefix? looking at similar attributes, we have things like aria-current rather than aria-iscurrent (though yes, on the other hand we have aria-haspopup, so the consistency battle has probably already been lost). just bikeshedding here...

[jnurthen]

The linked proposal (see https://lists.w3.org/Archives/Public/public-aria/2015Dec/0047.html ) doesn't have the is prefix so I'll discount that bit of the commentary.
I'm very happy to hear alternatives though - as long as we don't end up with something too generic like aria-actiontype :)
I'm also wondering if there is crossover to the personalization task force, specifically the simplification attribute

[ZoeBijl]

How about aria-buttonactiontyperole?

[mathalete]

what if it's a secondary action, but still important?

Yeah, good point. That's why I'd initially suggested there could be a granularity level that can be added to the attribute - a bit like aria-level. This might get a bit complicated for authors?

In saying that most of the design systems I've looked at recently do account for a primary and secondary control.

[yatil]

This should be in HTML, not in ARIA. I am really concerned how ARIA is getting a pseudo-HTML role but with even less cross browser/OS support and even less developer understanding and knowledge. Make that stuff easy to use and include it in standard HTML to see better adoption by everyone instead of developing stuff on the accessibility island. IMHO.

[mcking65]

@yatil commented:

This should be in HTML, not in ARIA. I am really concerned how ARIA is getting a pseudo-HTML role but with even less cross browser/OS support and even less developer understanding and knowledge. Make that stuff easy to use and include it in standard HTML to see better adoption by everyone instead of developing stuff on the accessibility island. IMHO.

If it is going to be in HTML, it needs to be in ARIA. It is a convenience for ARIA semantics to be implicit in HTML. Alignment is really important. The places where ARIA and HTML diverge are sometimes problematic.

For something like this, which is surely going to be highly experimental, ARIA is probably the better place to start.

[mcking65]

I think this is not just a screen reader issue. It is directly related to 4.3.1 Pattern: Make it Easy to Identify the Most Important Tasks and Features of the Site in Making Content Usable for People with Cognitive and Learning Disabilities. The guidance is:

Make important tasks and features on the site visually and programmatically prominent.

Currently, we have essentially no support for making an element programmatically prominent.

This issue represents a specific instance of that broader need. It seems like a useful starting point. While it seems reasonable to limit the scope to primary actions, we need to be careful about how the context and meaning of the action are programatically conveyed as well. Helping someone find buy now is wonderful if they are pressing the button to buy the thing they actually want. It is a disservice if they think they are buying X but are actually buying Y.

[mcking65]

I think we should limit the solution discussion to states and properties. Prominence and relative importance are characteristics of objects, not kinds of objects.

[patrickhlauke]

For something like this, which is surely going to be highly experimental, ARIA is probably the better place to start.

the problem is usually that things can start in ARIA, and then stay in ARIA and there's no follow-through, with the rationale that "well, it now works in screen readers, what more do you want?"

[patrickhlauke]

case in point, tri-state checkboxes or buttons that are pressed/not pressed. been in ARIA for aeons, but no sign of anything in HTML itself for these. it seems bizarre that fundamental states like that are simply only available to AT users and not part of the core language of the web itself.

[patrickhlauke]

tri-state checkboxes

the mighty @stevefaulkner reminded me that there is the indeterminate attribute in HTML now for these (though i'd question if it's obvious that a checkbox that has a mixed value is logically one that has an indeterminate state, but that's another matter)

[mcking65]

@mcking65 commented:

For something like this, which is surely going to be highly experimental, ARIA is probably the better place to start.

@patrickhlauke responded:

the problem is usually that things can start in ARIA, and then stay in ARIA and there's no follow-through, with the rationale that "well, it now works in screen readers, what more do you want?"

That is a valid question. Consider that a primary objective of ARIA is to express accessibility semantics programatically in accessibility APIs for the benefit of any technology that relise on those accessibility APIs.

If assistive technologies that rely on the accessibility APIs are deriving the intended benefit of a specific semantic, such as primary-action, and if authors are able to exploit the semantic to serve all users who can benefit from it, what additional objectives do we want to achieve when we define and implement a new accessibility semantic?

@patrickhlauke commented:

case in point, tri-state checkboxes or buttons that are pressed/not pressed. been in ARIA for aeons, but no sign of anything in HTML itself for these. it seems bizarre that fundamental states like that are simply only available to AT users and not part of the core language of the web itself.

Is it really the case that semantics such as partially checked are only available to AT users? Haven't those semantics been part of the web since people started combining HTML with other technologies, such as CSS and Javascript? I think those semantics were a core part of the web first and then we invented ARIA to ensure they could be declared explicitly in ways that AT could reliably parse.

Isn't the list of things that cannot be expressed in HTML alone but can be expressed by adding CSS and Javascript complemented by ARIA very long? In an ideal world, would that list not exist?

If we want to discuss these questions, we should move the discussion to another issue. I think it would be enlightening and beneficial to develop a stronger shared understanding of the scope of the technologies we are all collaborating to improve.

[patrickhlauke]

That is a valid question. Consider that a primary objective of ARIA is to express accessibility semantics programatically in accessibility APIs for the benefit of any technology that relise on those accessibility APIs.

but that's my point. these are semantics in general, and should not just be limited to AT users. otherwise, may just say that authors can just use divs and spans, as long as they just inject the right semantics with ARIA, because who cares about semantics other than AT users.

Isn't the list of things that cannot be expressed in HTML alone but can be expressed by adding CSS and Javascript complemented by ARIA very long? In an ideal world, would that list not exist?

and again, that's my point. that's already a problem, so saying "there's already so much that HTML can't express that ARIA can, so one more thing won't make a difference" is disingenuous. for something that's completely new, as discussed here, why not try and do the right thing and add it to HTML, instead of just taking a shortcut via ARIA, non-AT uses be darned?

[patrickhlauke]

Haven't those semantics been part of the web since people started combining HTML with other technologies, such as CSS and Javascript?

CSS and JS do not add "semantics". semantics need to be unambiguously machine-readable. so not quite sure what point you're trying to make here. [edit: at least that's what we developers understand when talking about "semantics" ... see also Sir Tim's take - Semantic web (wikipedia)]

[jnurthen]

This seems to fit in with the openui button explorations.
https://open-ui.org/components/button/

[patrickhlauke]

years later, and i'm still not sold on this whole concept of making a specific, ARIA-only concept here (unless the pointer to openUI is an indication that perhaps this should be enshrined in actual HTML)

[jnurthen]

years later, and i'm still not sold on this whole concept of making a specific, ARIA-only concept here (unless the pointer to openUI is an indication that perhaps this should be enshrined in actual HTML)

Which is why I think it might fit better in openui

[mathalete]

Focussing on the outcome, I'd support the HTML route, if that's OpenUi, fair enough.

Wouldn't the same rationale apply to aria-current though?

[patrickhlauke]

Wouldn't the same rationale apply to aria-current though?

it does, but that horse has already bolted ages ago, so unlikely to get any traction with HTML folks...

[MarioBatusic]

I think the same rationale applies to the whole ARIA. The best way for authors and for users would be to have the complete document semantics and UI semantics directly in HTML. But does it mean, that we should stop defining ARIA semantics? Or is it still a good idea to have ARIA as first, initial project on the way to the ever better HTML / made hopefully now through the efforts op openUI?
So I trhink that an aria-pominent or similar on links and buttons supported by a specific action possibility in different ATs would be a good idea.

[pkra]

As per editors' call, closing this for the time being. OpenUI or other community group seems like the better way to move this forward.