SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    SitePoint Enthusiast
    Join Date
    Jul 2011
    Location
    Hull, UK
    Posts
    78
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Call to action within a block wrapped link

    Hi all,

    I received a design for a homepage that displays recent articles. These articles are wrapped within an all encompassing anchor tag (allowed by the HTML5 spec as far as I am aware). The article all contains a call to action type element e.g. 'Book a ticket' that was formally the link before it was decided that the link would cover the whole article element.

    HTML Code:
    <article>
    			<a href="#">
    				<img src="images/homepage/XXXX.jpg" width="354" height="209" />
    				<h1>Gig title</h1>
    				<p>Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit</p>
    				<span class="readmore">Book a ticket</span><!--Formally a link-->
    			</a>
    </article>
    Is this accessible?
    - I don't believe it would be (I think because the span is not in direct context of the anchor tag? Is this correct?)

    Look forward to hearing your thoughts, thanks

    Jonno

  2. #2
    SitePoint Wizard bronze trophy bluedreamer's Avatar
    Join Date
    Jul 2005
    Location
    Middle England
    Posts
    3,392
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    That's perfectly acceptable for HTML5 and fully accessible I'd say. A screen reader for instance would read "link blah blah... heading... gig title... etc etc", the screen reader will be aware that the text is inside a link...

  3. #3
    Life is not a malfunction gold trophysilver trophybronze trophy
    TechnoBear's Avatar
    Join Date
    Jun 2011
    Location
    Argyll, Scotland
    Posts
    6,352
    Mentioned
    268 Post(s)
    Tagged
    5 Thread(s)
    When a screen reader reads the link, will it be obvious that the purpose of visiting that link is to book a ticket? Or will a user need to listen through the entire thing to work that out?
    Quote Originally Posted by bluedreamer View Post
    A screen reader for instance would read "link blah blah... heading... gig title... etc etc", the screen reader will be aware that the text is inside a link...
    But more to the point, will the user still be aware that this is a link and they can interact with it?

    I'm asking because, like the OP, I have only a hazy idea how these things work and would like to understand a bit better.

  4. #4
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,281
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    It can make some trouble but mostly what I've heard from other people is, the links get so long it gets hard to tell which text is still the link and which isn't. It also makes navigation by lists-of-links a bit of a b*tch, because they become sooooo loooooong. Longcat is loooooooong.

    In the above example you also have other things in there, like headings, which have both different navigation methods (you can navigate a page by heading) and different native HTML roles (role="heading").

    Assuming someone is skimming these blocky links by heading, it may or may not be made clear by the AT that the heading is within a link.

    Now honestly, *most* of the time you get code like the above:
    Code:
    <article>
      <a href="#">
        <img src="images/homepage/XXXX.jpg" width="354" height="209" />
        <h1>Gig title</h1>
        <p>Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit</p>
        <span class="readmore">Book a ticket</span><!--Formally a link-->
      </a>
    </article>
    ...the only reason you're wrapping everything in a link is because you want it all to be easily clickable for users, usually mouse users and possibly also touch users. Usually increasing the hit area is a Good Thing, but there are some other ways to do it without wrapping everything in one big link. It might be worth it to try to get around it and do it HTML4-style. Also if you're still supporting older IE (7, 8) they did used to have issues with the anchors-around-blocks thing. Maybe not even 8 that much. This mostly comes from, when the HTML5 people thought "let's implement this anchors-around-blocks" thing, they were relying on the fact that most browsers' error handling made it possible anyway to wrap links around blocks, and so this seemed a backwards-compatible thing they could do where the only real change was the validator getting updated :P

    What we're doing in our e-commerce area, where we have lists of products showing an image, a product name, possibly a description and a few other clickable things like "compare" checkbox, and sometimes an input for number of items + add-to-cart button (or, in place of those last two, a link that looks like a button called "view product"), we often want as much of the product block clickable to the main product page as reasonably possible.

    Because I found the amount of content waaay too much to gamble that AT would behave correctly (also keep in mind that users often have both older browsers than you-the-developer, and *very* often older AT, especially if they use commercial AT which is expensive as hell), so I tried a few other things:

    I have both the image and the name of the product in the link.
    Code:
    <a class="product_image">
      <img of product>
      <span>Product name</span>
    </a>
    Then, if we have a product view where the product boxes are long and wide (they used to be tables), there'll often be a big chunk of text with a product description.

    I ended up scriping these to have an onclick event which grabs the URL of the anchor I mentioned above and takes mouse (and likely touch users) to the product page if they click that. I also style mouse hovers of the cursor to look like a hand with cursor: pointer.

    On top of that, I'll also script in a .hovered class to the whole block: with this hovered class, which often times I only style for keyboard users, the whole product box gets highlighted when the user is focussed on that anchor with the image. Since there could be a few other clickable things in there that don't take you to the product page, I remove the highlight usually if the user tabs to these other things.

    So this is how I get large clickable areas for mouse users, while retaining some sanity in my HTML with the links.

    What *I* would be doing with the above code:
    Code:
    <article>
      <a href="backuplink">
        <img src="images/homepage/XXXX.jpg" width="354" height="209" alt="Book a ticket for (name of this one)!"/></a>
        <h1>Gig title</h1>
        <p>Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit</p>
        <a class="readmore" href="backuplink">Book a ticket</a><!--a link again, since now you get a link-with-call-to-action -->
      </a>
    </article>
    (and you could add negative tab index to the first link so sighted keyboarders get one Tab per gig)
    And something like
    Code:
    $('article').each(function() {
      var article = $(this),
            url = article.find('a:first').prop('href');
      article.on('click', 'h1, p', function(){
          window.location = url;
      });
    });
    except less crappy and hopefully not in jQuery. Bleh.
    Also of course a .readmore:focus {obvious but nice-for-design style here;} : )



    -----------------------------------
    Another, JS-less way to do it would be multiple anchors. You can add tabindex="-1" on those to prevent sighted keyboarders from a Thousand Tabs of Death, but it won't stop screen readers and other AT from offering them in a list of links, meaning you'd kinda be "polluting" the list-of-links bit of your page.

    I use this second technique on my own web page, but it's combined with aria-hidden and role="presentation":
    Code:
              <li>
                <h4><a href="http://drmcninja.com/">Dr McNinja</a></h4>
                <p><a href="http://drmcninja.com/" aria-hidden="true" role="presentation" tabindex="-1">
                  <img src="furnimg/mcninja.jpg" width="55" height="55" alt="" role="presentation"></a>
                  He’s a doctor who’s a ninja... a ninja who’s a doctor. Awesome. M,W,F</p>
              </li>
    You generally do not ever want presentational roles or aria-hidden on clickable thingies!! This may cause name-less thingies getting focus if you don't also use a negative tab index!!
    The reason this works in this setup is because the image is almost entirely decoration and additionally for more clicky-areas for mousers-- some people just prefer to click on thumbnails instead of link text. Because I'm considering the anchor and its image as presentational-because-redundant, I feel okay using this. The heading with the name of the comic, with link inside, and the description below are what I want *everyone* to have as a basis, not necessarily that there are also some unlabled thumbnails involved as well.

    Both screen reader users and sighted keyboarders avoid Thousand Tabs of Death.


    A third setup, which wouldn't work with either my above code or the OP's original code, is to have lots of top-padding on a position: relative container element, place either the image or a background image in that padded area, and extend the anchor padding up to that area so there's a single anchor but a large clickable area. I do this in our main product category pages where clients want not only the <h2> heading clickable but also the category image. Just be careful not to cover over non-link text with the anchor-- it will be readable by screen reader but not highlightable or copyable by mouse users.

    Code:
    <div id="tree_index">
    <ul>
      <li>
        <h2><a href="to product cat">PRODUCT CAT NAME</a></h2>
        <img of category>
        <ul>
          <li>Category items...</li>
         ...
        </ul>
      </li>
      ....
    </ul>
    </div>
    where
    #tree_index ul>li gets position: relative
    #tree_index h2 a gets top-padding a bit more than height of image plus h2 margins or anything else, and display: block, and position-relative for a z-index
    #tree_index h2+img gets absolutely-positioned at the top and left, minus any side paddings I want on the li

    Because there's no text above the h2, I can get away with this, while giving a large clickable area. The HTML was originally written for something else, which is why the CSS is a bit convoluted (plus I like headings to come before related images, since I see headings as heading content and the image as content being headed...).


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •