CODEWITHSUNDEEP
jqueryhtmlaccessibility
Jeromy French
Jeromy French

Reputation: 12121

Adding HTML5 hidden attribute support to jQuery .toggle() method

I'd like to pair HTML5 hidden support with jQuery's .toggle() method.

So given <p id="myElement">Hi there</p>

$('#myElement').toggle() would hide the element, and set hidden="hidden":

<p id="myElement" style="display: none;" hidden="hidden">Hi there</p>

And executing the same $('#myElement').toggle() script again would show (toggle) the element, and remove the hidden="hidden" property (it is a boolean):

<p id="myElement" style="display: inline">Hi there</p>

I probably want to use the complete function of the method, maybe something along the lines of 

$('#myElement').toggle(
    if ($this.css('display')==='none'){
       $this.prop('hidden', 'hidden');
    }
    else
    {
       $this.removeProp('hidden');
    }
)

What's the most performant solution for extending .toggle() to also toggle the HTML5 hidden attribute? Is it redundant to do so?

This question is a variation of Adding WAI-ARIA support to jQuery .toggle() method; it was determined that it would be redundant to toggle the aria-hidden state in conjunction with toggling the element's display.

Upvotes: 4

Views: 15186

Answers (2)

Jeromy French
Jeromy French

Reputation: 12121

The hidden property can be toggled using the complete function of the .toggle() method:

$('#myElement').toggle(function() {
    if ($(this).css('display')==='none'){
       $(this).prop('hidden', 'hidden');
    }
    else
    {
       $(this).removeProp('hidden');
    }
})

See http://jsfiddle.net/jhfrench/g8Sqy/ for a working example

Notes:

  • use $(this), not $this
  • need to declare a function (.toggle(function() {...}), not .toggle(...)
  • using the callback to toggle hidden is really, really slower than plain-old .toggle()

Upvotes: 2

BrendanMcK
BrendanMcK

Reputation: 14498

Some commentary on this that may or may not be useful - putting this as an answer as it's too long to fit into a comment :-) -

While the idea behind hidden is that it has potential to provide better accessibility than display:none (it doesn't require an accessibility tool to be aware of the CSS), there's currently no concrete or testable benefit that I know of - given that screenreaders support the CSS approach anyway.

(...or rather, the browsers that screenreaders work with already parse the CSS and pass the hidden information on to the screenreaders via the platform's accessibility API. Likely the main tools to benefit from hidden will be other accessibility tools that work directly with their own copy of the DOM rather than communicating with a 'host' browser.)

(Also, while in a perfect world, CSS would be purely presentational, it's often not. Use of display:none is one case where it's not - it is often used to indicate that content is not currently relevant, which is semantic information; and the hidden does address this case; but there's still other cases that have to also be addressed: generated content is perhaps the main other case.)

I'm somewhat hesitant to adopt new features until I can verify them behaving and working as planned: it's not uncommon for new features to be spec'd one way, but end up being implemented in a subtly different way that has implications for how the feature can practically be used. (Use of the ARIA role="application" is a good example of a feature that has plenty of caveats.) And at the end of the day, it's not adherence to the spec that makes a page accessible or not, as it is how the whole combination of content, browser and screenreader (or other accessibility tool) work together that matters to the end-user.

Another issue to be aware of: the HTML5 spec says of the hidden attribute:

[...] For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation [...]

However, tabbed dialogs are a common use-case for jQuery's toggle/show/hide/etc methods; so applying hidden in all those cases might be [technically] against the spec. Seems the same reasoning would apply to page menubars and their popup menus also.

Upvotes: 2

Related Questions