Monday, February 20, 2012

aria-hidden and role="presentation"

John Foliot pinged me about his blog post devoted to ARIA techniques used to hide the content from assistive technologies. Since I don't have straight answer then I decided to put my thoughts here.

presentation role
ARIA role="presentation" technique is intended to hide an element from AT users. A classical example is presentational images. If you place role="presentation" on the image then it gets removed from accessible tree. Also this technique can be used to remove HTML table semantics, i.e. if role="presentation" is specified on HTML table then table structure is not exposed.

ARIA role="presentation" is completely ignored if it's used on focusable element. That means the element isn't removed from accessible tree and its native semantic is exposed. For example, if you put this role on HTML button then it's revealed as normal HTML button to AT. This is reasonable because if the user focuses the button then focus doesn't get lost and screen reader announces something meaningful.

aria-hidden
The most noticeable difference from role="presentation" is aria-hidden affects on whole subtree. John gave a good use case: hide excess links from screen reader users. A common pattern is a clickable image inside HTML:a element. ARIA spec confirms this saying "Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content."

I should notice that ARIA is not designed to change visual presentation and affect on behavior. Thus if this is an ordinal link then no ARIA technique can be used to hide it from screen reader user since this contradicts to ARIA design. But if the author puts @tabindex="-1" on the link to make it unfocusable then aria-hidden looks like a proper way to achieve desired result.

Technical side
ARIA implementation guide allows to remove elements with aria-hidden from accessible tree but it doesn't require that. Also it states "If the object is in the accessibility tree, map all attributes as normal. In addition, expose object attribute hidden:true". Additionally it points that if the aria-hidden attribute is changed then the browser should emit attribute_changed event (in case of IAccessible2). That's exactly what Firefox does.

So Firefox does a minimal implementation of aria-hidden allowing a screen reader to do what it thinks it should. That means each screen readers should invent a wheel and actually that what happens (or doesn't) - check this table to see how Firefox is different depending on screen reader running.

Implementation of aria-hidden both on browser side and screen reader side is not straightforward. For example if some element having aria-hidden contains a focusable element then its *whole* subtree can't be ignored. At the first glance reasonable solution would be if the browser doesn't create an accessible for each element in subtree until the element is focusable, in other words it treats aria-hidden as role="presentation" was specified on each node in subtree. Otherwise AT needs to crawl the accessible tree to check if there's an element with aria-hidden in ancestor chain. The current Firefox implementation forces AT to do that.

Things to think about.
If the browser doesn't create an accessible for aria-hidden subtree then there is a black box having certain dimensions on the screen. Thus if the user investigates the page layout by mouse then screen reader says nothing when the mouse pointer is above that black box but if the user clicks at this area then he gets unexpected behavior.

On the other hand some screen magnifiers use dimensions of accessible objects for page zooming. No accessible then zoom is likely broken.

So at the second glance I think aria-hidden shouldn't change the tree at all. Instead the browser should expose hidden:true object attribute on every accessible from the subtree of aria-hidden element. That allows AT to decide whether they want to ignore the accessible or not and prevents AT to crawl the accessible hierarchy.

I'd say this rule should be applicable to role="presentation" as well. So if the user explorers the page by mouse then screen reader can say this is presentational image but exclude it from keyboard navigation.

14 comments:

  1. Alex, your comment that ARIA is not supposed to change the visual presentation is true. However, it is not prevented from deciding what is exposed to an assistive technology. So, in this sense I think you overstated the situation.

    Microsoft has decided that they would not expose content with aria-hidden="true" to an AT. Mozilla has chosen otherwise. ARIA is meant to expose the intent of the author. I do agree with you that the use of aria-hidden could be misused. So, I don't have an issue with the Firefox implementation. I have a minor concern over IE's implementation for that reason. I had hoped that the browsers would reach a common implementation but they have not. So, there you have it.

    aria-hidden was meant for dom based AT to let them know what was intended by the author.

    ReplyDelete
  2. Note: in the planned full UIA implementation (this has not been fully implemented in IE) the plan is to expose the accessibility tree with hidden="true" in the aria properties so eventually it appears the two will be consistent.

    ReplyDelete
  3. Recently we've got some discussion in Mozilla bug about aria-hidden. I start to think that invisible state might be a best fit.

    ReplyDelete
  4. aşk kitapları
    youtube abone satın al
    takipçi satın al
    takipçi satın al
    takipçi satın al
    takipcialdim.com/tiktok-takipci-satin-al/
    instagram beğeni satın al
    beğeni satın al
    btcturk
    tiktok izlenme satın al
    sms onay
    youtube izlenme satın al
    tiktok jeton hilesi
    tiktok beğeni satın al
    takipçi satın al
    uc satın al
    sms onay
    sms onay
    tiktok takipçi satın al
    tiktok beğeni satın al
    twitter takipçi satın al
    trend topic satın al
    youtube abone satın al
    instagram beğeni satın al
    tiktok beğeni satın al
    twitter takipçi satın al
    trend topic satın al
    youtube abone satın al
    takipcialdim.com/instagram-begeni-satin-al/
    perde modelleri
    instagram takipçi satın al
    instagram takipçi satın al
    takipçi satın al
    instagram takipçi satın al

    ReplyDelete
  5. I think you can make youtube video about these techniques, can't you? If you worry about likes under your video use this site https://soclikes.com/ to get some likes

    ReplyDelete
  6. Satya Puri Studio is Bali Construction have worked on historically-inspired homes & villa around the world — including “Lux Villa in Bali; Sukh Sagar Haveli in Jodhpur, Rajasthan; Kahani Paradise in Gokarna. Their work shows inspiration across history and styles, tied together with the goal of enhancing life through good design.

    ReplyDelete

  7. Looking to incorporate your company in Bali? GRO Indonesia has a notable experience in dealing with company establishment. We have managed to assist a number of companies to assist them in processing their legal documents. We have a range of service options depending on your needs, which allow businesses to have a legal presence in Indonesia.

    ReplyDelete
  8. It's too bad to check your article late. I wonder what it would be if we met a little faster. I want to exchange a little more, but please visit my site 온라인카지노 and leave a message!!


    ReplyDelete
  9. Hii,
    This is great and awsome post for me. i loved to read your blog. it's really-really amazing. thanks for inspired me by your blog.Online Garen Store
    Buy Golden Jhumka
    Buy Online Seeds
    Buy Handicrafts Online
    Book Resin Planter
    Buy ZZ Plant Online India
    Buy Bunny Ear Cactus

    ReplyDelete