Overview

Often when developing a web page, it can make sense to hide specific aspects of the page until a certain action occurs, which causes them to appear. A common example of this is navigation menus, which when navigated to sometimes display child items of the navigation menu in a list. The child elements of the navigation menu are often styled using CSS to be hidden by default, then shown when interacted with by using Javascript. Basic stuff, right? In the following post I’d like to explain the common pitfalls with hidden content and how it interacts with the accessibility tree. No idea what the accessibility tree is? Don’t worry, we’ll cover that too.

The Document Object Model and the Accessibility Tree

The Document Object Model (DOM) is what it says on the tin, a method to gather up information processed in the page source, and provide it in an object model, which can be interacted with and programmatically manipulated. For example, one of the most used commands in Javascript is document.getElementById which directly accesses the DOM to allow the user to reference an element, and with further logic be able to manipulate its attributes, styling and more.

The Accessibility Tree is a subset of the DOM, that mirrors each element included in the DOM, but strips out the unneeded parts which wouldn’t be beneficial for assistive technologies. In short, this is what is presented to assistive technologies who want to digest and interact with a web page.

It is important to understand that how each browser builds its DOM and Accessibility Tree will be different. Also their support for newer markup such as HTML5 and WAI-ARIA might be limited. That is why it is important to test what you plan to implement with various browsers and assistive tech.

Understanding the DOM and Accessibility Tree doesn’t really matter, but being able to identify why something may, or may not be picked by assistive tech does.

Hiding content from the Accessibility Tree with CSS

Using CSS we can hide an element from the page using either display: none;, or visibility: hidden;.

Although other methods of hiding elements with CSS exist, both of the above CSS properties are most commonly used. They have one common problem: both are completely ignored by assistive technologies! Now the fact that they are ignored is not a bad thing, but it does lead to misuse, which in turn creates accessibility problems.

So let’s look at some examples of where it could go wrong.

Hidden form labels

JD Sports have many flaws with their website, but let’s only consider their search field for now.

Example of a labelless search input field, used on the JD Sports website.

Labelless search fields are quite common these days. They can impact accessibility in a few ways, but let’s just consider one: a field without a label. Now for assistive technology this creates a problem as the field will make no sense. For most it will simply be interpreted as an edit field. So to counter this we would add a label for the input field, to explain its purpose to assistive technology.

For purely the label aspect JD Sports do a couple of things wrong:

1. They correctly create a label for the input field, but don’t relate it to the field by using the label for attribute.

Incorrect:

<label>Search site</label>

Correct:

<label for="ID">Search site</label>

2. The input field for the search field also doesn’t have an ID attribute to map the label for to.

Incorrect:

<input name="freeText" type="text" />

Correct:

<input id="search" name="freeText" type="text" />

3. The final nail in the coffin though, and the one that we care about most in the context of this discussion, is their use of display: none on the search label.

I see this a lot! It drives me nutz, because knowingly, or not it defeats the purpose of the accessibility feature they have attempted to add. Of course though, not everyone understands that display: none;, or visibility: hidden; are ignored by assistive tech. In the case of JD Sports though, however had built their site is clearly a bit of a cowboy, who doesn’t really know what they’re doing.

So if you can’t hide it with display: none, or visibility: hidden then what do you do?

Display accessible content off screen

Well you can of course display it off screen, so that it is visually hidden, but can still be picked up by assistive tech. So in the case of JD Sports it would be something like so:

HTML

<label class="hidden" for="search">Search site</label>

CSS

.hidden {
position:absolute;
left:-10000px;}

Now this is my prefered method, but as Jonathan Snook correctly points out in his article hiding content for accessibility, this won’t work cosmetically for right to left languages. If you don’t have to concern yourself with RTL languages, then don’t worry. Otherwise use his suggested solution below:

CSS

.hidden {
position: absolute !important;
height: 1px; width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

Hidden navigation menus

Ok simple stuff, right? So what if we go for something a little bigger, like a navigation menu?

On the Poundland website, and countless others, they use display:none; to hide the contents of the drop down navigation menus until they are selected. Makes sense you would think. Let’s also assume that your dropdown navigation menu is keyboard accessible. It would still make sense, because when the user focuses on the top level navigation item, the child elements we assume will become unhidden? Wrong! We can’t predict that all users will interact with a web page in the same way. Keyboard navigation may be one choice – another option though might be to scan the page line by line with assistive tech, or use keyboard shortcuts to get where you want in a document before scanning its contents. This scenario wouldn’t work, as the child navigation items would be hidden from assistive techs view, so they would only pick up on the top level navigation items, not the hidden contents.

Example of Poundland hiding content from users of assistive tech, with display:none;.

Again an off left technique would work fine here, which can be toggled using JavaScript to appear back on screen when in focus. The rule of thumb for elements which can be navigated to using the tab key, is to bring them back on screen when focused upon.

There are some scenarios where you may genuinely require an offscreen navigation element which would never appear on screen when in focus. The BBC for example use an accessible skip link, for users to skip the navigation and go straight to content. Their implementation jumps to an off screen navigation link, which is excluded from normal keyboard navigation by setting the elements tabindex attribute to -1 (exclude from tab order), but still focusable by setting focus using JavaScript.

SEO and CSS off screen techniques

Now hiding content off screen for accessibility purposes is all good, but couldn’t that be abused to improve search engine rankings? Of course it could, but thankfully search engines are clever enough to know when someone is abusing this or not. Keyword spamming off screen might downgrade your ranking, and if bad enough remove you from search listings altogether, but providing accessible information and links will not.

Google Webmaster Tools, have an article explaining this in their help sections, titled: Hidden text and links.

Putting display: none;, or visibility:hidden; to good use

So when does it make sense to use display: none;, or visibility: hidden;?

Well most sites in the UK now have a cookie policy message which appears the first time you visit a website. This is now a legal obligation which sites have to make you aware of, they don’t require you to accept it, they just need to present it to you on your first visit.

The Scottish Government has an odd example which admittedly isn’t fully accessible in its current implementation, but makes a good use case for using display:none; (and it does).

Scottish goverment website example of using display:none;.

After you have seen this cookie policy once, you’ll not need to see it again. Likewise for assistive tech, if you’ve read it once, you can effectively ignore it. Making use of display:none; here to hide the entire element that contains the cookie policy, allows assistive tech to effectively never process it again. Next time you visit the site, the div (element) that contains the cookies policy popup will be hidden using display:none;. This means that users of assistive tech do not need to process it again. If they styled it to appear off screen like we’d suggested for the previous examples, then visually normal users wouldn’t have seen it, but assistive tech would have still picked up on it.

Play around with the Scottish Government example and see if you can spot their accessibility mistakes with this cookie control. There is also a blatant lie in regards to cookies. See if you can spot it. No prizes, but I’m keen to see if anyone can spot the mistakes. Using what you’ve learned so far you should be able to.

A checkout process might be another example of when it might make sense to use display: none;. You might require data to be entered into the current step, before being able to progress to the next. So if you didn’t use display:none; here, then you might confuse users of assistive tech who would be able to read steps that visual users can’t, for good reason.

Other problematic CSS

VoiceOver by Apple has accessibility issues when an element’s height or width is set to zero. An element with this style applied will be ignored. Enrique Palazzo as far as I can tell was the first person to identify this issue on a Drupal issue ticket.

Kent County Council at the time of writing introduce this issue for VoiceOver users on their off screen skip links.

Example of Kent councils websites, impacting Voiceover users, with a height and width of zero.

It is easily fixed though by increasing the width and height to 1px.

While we are on the topic of faulty skip links, the UK Government’s Digital Service website hide their skip link with display:none;. Interesting when it is supposed to be a pioneer for government digital content.

Example of the UK goverments Digital Service website, hiding their skip link with display:none;.

So using CSS to hide elements from the page isn’t a terrible thing to do in regards to accessibility. The main problem is the misuse of it, and being able to understand when it should, or shouldn’t be used.

Problematic JavaScript

Everybody and their mom these days uses JQuery. Why? Well it’s a lot simpler to do things in JQuery than it is in JavaScript.

JQuery has a lot of methods that present accessibility issues if misused:

.hide()
.fadeOut()
.fadeToggle()
.slideToggle()
.slideUp()
.toggle()

Each of these adds display:none; inline to the element, which depending upon the context of its usage, could present accessibility issues. So when using any of these methods, like in our previous CSS examples, it would only makes sense to use them, if the context of there useage doesn’t impact accessibility.

JQuery also gives you a few DOM manipulation techniques, that obviously affect the Accessibility Tree:

.detach()
.remove()

There are others, but these are the two most commonly used. The main difference between the two is that .detach() will allow you to bring the element back into the DOM, .remove() won’t. Again use with caution. In the case of a cookie policy message that is only ever viewed once by the user, either of these might be a good option.

Another problem comes from inaccessible JavaScript methods for adding content:

write()
innerHTML()

The problem with both, is that they don’t interact with the DOM. As such elements added via these methods most likely will be ignored by all assistive tech. So avoid these like the plague!

Build a bear is one of my daughters favourite shops. They commit a double crime, with their flash not enabled warning. Firstly they exclude it from assistive tech as the write() method isn’t interacting with the DOM. Next they write in an image, with no alternative description. So they may as well display nothing, for all the use it provides to assistive technologies.

Example of the Build a bear websites, no flash warning.

Obviously analysing Javascript adds a little more complexity onto your testing efforts. The most obvious way to test this, is to use some assistive technology to interact with the page, and see what is being picked up, or not. Personally I prefer to do some quick tests in developer tools, by inspecting inline and external JavaScript and searching (CTRL + F) for problematic methods, to see what they are doing. This way you can quickly identify where on pages they’ll be used, and test to confirm your suspicions with assistive tech.

Hiding content with HTML

There is a couple of attributes in HTML that can hide content from assistive tech.

Hidden input fields

The first is the input element’s type attribute. If the value of its attribute is set to hidden then obviously the field will be hidden from view. Assistive tech treats it exactly the same by ignoring it.

HTML

<input name="Language" type="hidden" value="English" />

It is actually quite a common technique, that is used on most websites, to store values. Back in the days of caveman development, when entire websites used to be constructed of forms to control layout, you could often see username and passwords being submitted in hidden fields as a form of access control. Thankfully those days are long gone.

So this technique isn’t so bad, depending upon how you use it. It’s pretty hard to mess this one up.

Alt tag

As a general rule of thumb if an image adds descriptive value to the context of a page, then add alternative text for it using the alt attribute. If it is purely for decoration, add the alt attribute but leave it empty.

HTML

<img src="randompicture.png" alt="" width="150" height="10" />

The above randompicture.png image if used purely for decorative purposes, would correctly have a null alt attribute value. Many assistive technologies will choose to ignore the element completely, as with an empty alt description, they assume it is for decorative purposes.

You might also add an image on a button with the type image, or a link anchor with an image inside it.

HTML

<a href="register.aspx">
<img class="overlaybtn" src="register.png" alt="" width="32" height="12" />Register</a>

In the above example you might confuse the need for adding alt text if the image overlaps the anchors link description. As the anchor already has a link description “Register” adding the alt of “Register” again would merely duplicate the content. For most assistive tech, duplicate content would be read twice, sometimes without any context, e.g. image alt: register, register link, might simply be processed as register, register link.

So it’s worthwhile noting that alt attributes with a empty value will be ignored by assistive technologies. Let’s not talk another further about the specifics of alt attributes and how to use them correctly, because that is a topic for another time, and already covered in great detail all over the web.

HTML5 hidden attribute

HTML5 brought us a new attribute called hidden, which when used hides the element it has been applied to from view.

As far as I could tell, all current browsers that support this attribute, simply apply a style of display:none; to the element. So effectively when used this will be ignored by screen readers, so use with care. As we have already discussed with the CSS technique, sometimes it is useful to use display:none; and other times it can impact accessibility.

.hidden {
position: absolute !important;
height: 1px; width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

<a tabindex="-1" href="#maincontent">Skip to content</a>

Hiding content from the Accessibility Tree with WAI-ARIA

WAI-ARIA introduces a couple of ways to hide content from assistive technologies.

The aria-hidden attribute

Sometimes it might make sense to hide visual content from assistive technologies. To do this we make use of the aria-hidden attribute. If you are displaying duplicate content because it fits with the design, rather than having the content interpreted twice by a users of assistive tech, you can hide the most sensible instance using aria-hidden.

HTML

<img src="decorative.png" alt="" aria-hidden="true" />

In the above example HTML it might even make sense to use aria-hidden to make sure decorative images are not read out by assistive technology. Although some assistive tech will ignore images with empty alt tags, not all will, so doubling up with aria-hidden=”true” helps our chances. I say chance, because support in both assistive technologies and browsers is a bit lacking.

Presentation role

The presentation role, is used to convey that an element is used for presentational purposes only. As such, these elements would provide no benefit to users of assistive technologies and should therefore be ignored.

HTML

<img src="decorative.png" alt="" aria-hidden="true" role="presentation" />

Again using the same example as used in the aria-hidden example, specifying an element with the presentation role, further increases our chances of it being ignored by assistive tech, but still having it remain visually on screen.

Specification example use cases:
1. An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
1. An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
2. An element used as an additional markup “hook” for CSS; or
3. A layout table and/or any of its associated rows, cells, etc.

So useful, but again lacking real support from browsers and assistive technologies.

Summary

So I hope you are now more aware of how elements can be intentionally, or unintentionally hidden from assistive technologies. There is a lot to consider, but the most important aspect, is to consider the context of the element/container in question before deciding if the technique is correct, or not.

Thanks for reading.

Overview

Tonight I had the opportunity to attend my 2nd Scottish Usability Professionals’ Association event in Edinburgh.  It was a good night which saw two speakers from the University of Abertay delivering two very different talks.

I am not going to talk about both.  Instead I would like to share my notes and thoughts on Dr Jackie Archibald’s talk titled: Emotional Avatars – What and Why, which I found extremely interesting and thought provoking.

Emotions

The talk saw Jackie begin by explaining the role emotion plays in modern day human computer interactions.  She discussed aspects such as perception, cognition, creativity and our ability to cope as reactions triggered by our emotions.  She also discussed how our current emotions can affect our memory, ability to plan, or complete tasks, and our ability to make decisions.  She went on to explain how displaying your emotions can often be seen as a negative thing.  People may questions your ability to work logical, or even think rationally.  However, she explained that emotion is important, and can aid interaction in an intelligent way.

Avatars

With the reasoning out of the way, next came the interesting part – emotional avatars.  She explained that an emotional avatar, was simply a virtual character who could display, and / or recognise emotions.  The use for them she suggested could be in education, training and as help systems.  She provided a example of a virtual avatar which was used in New Zealand to help teach kids working from home, which could help guide them through lessons.  This was called Easy with Eve, and supposedly could detect facial patterns in students and react to them.

She provided a few more examples, of avatars currently in use:

• Asking Anna, the IKEA bot
• Ask Rachel, Tesco
• Virtual agent Sasha, Kaspersky

Jackie, showing Virtual agent Sasha, the Kaspersky bot.

All very interesting and sharing one common trait – they are all provide support desk type feedback.  Perhaps this is how future FAQs (frequently asked questions) will turn out?  None from what I could gather had any concept of emotions, but simply how to display them.

Now the talk became more interesting as Jackie went on to explain the research three of her students had done around this area.

Dealing with frustration

The first student, John Hart had completed a research project titled “Dealing with frustration”.   He began by surveying opinions on virtual agents such as the Asking Anna IKEA bot.  The general feedback not surprisingly, was that people were not overly impressed by them.

For the next step of his project, John developed a travel website which intentionally frustrated users with introduced delays and broken links.  As people used the site it was noted their frustration levels began to rise.

His final step was to develop an emotional avatar, which would see if it could assist in reducing user frustrations.  He would then be able to introduce an agent to help assist the user, using affective language via a text based conversation panel.

What he found was:

• Users were both frustrated with the avatar and the website.
• Avatar frustrations seemed to stem from its limited knowledge base, meaning it struggled to answer certain questions asked of it during the studies.
  • The avatar provided no help to overly frustrated users.
  • Moderately frustrated users which it successfully responded to, noted reduced frustration levels to some extent.

Interesting, but without seeing the research myself it is hard to make much of it.  The approach appears open to a lot of bias and assumptions.  The fact that surveys were employed as a research tool, doesn’t hold much weight really in my opinion.  How, or when he decided to inject the avatar as well, I’m unsure of.  Still, it is very interesting and opens up ideas for how these could be used as a means of online engagement with users based upon some sort of emotional rules engine.

Improving self service systems via emotional virtual agents

Next up was PHD student Chris Martin, who was doing a research project titled: Towards improvement of self service systems via emotional virtual agents.  This project looked into how the user experience of a self service system such as a supermarket self service checkout.  The idea being that an empathetic system could be developed, which could understand, reason and react to peoples emotions.

The first stage of his project involved filming (with permission) people using supermarket self service checkouts, and noting their facial reactions while using them.  These would be logged as facial action units and when reviewed patterns could be identified.  It was found that the two most common action units related to anger.

For his next stage, knowing that anger was the most common response to these systems, he wanted to determine the most appropriate response an agent should provide to the user.  To do this he created a system which would mimic a self service checkout, but intentionally block the users from completing their task.  At this point, an affective agents (emotional avatar) would be introduced, and their response to the avatar would be recorded.  Seven different types of avatar were used to determine which was most suitable.  Each of these had a different facial expression:

• Anger
• Disgust
• Fear
• Neutral
• Happy
• Sadness
• Surprise

Of these, the one found to be the most inappropriate to use was disgust.  The one which received the most positive reaction was the neutral avatar.  I sought clarification after the talk if text was displayed to the user to match these differing emotions, but it appears that only an avatar image was presented to the user.  I assume some processes were still available to the user at this point to progress or cancel the checkout process though.

Usable security via affective feedback

The final research project titled: Usable security via affective feedback, was being done by a student named Lynsay Shepherd.  This one though was only just starting, so there wasn’t much to cover research wise, as none had really been done yet.

This project would look at how systems could improve risk awareness in end users using affective feedback.  Users would then become more aware of the risks their behaviour could introduce.

Thoughts

All in all, it was a really interesting talk and for that reason alone I’m glad I took the time out to attend.  I struggle though to see how avatars using current technology can react to end users.  I did ask the question and Jackie provided a decent enough response, although perhaps not quite what I was looking for:

• Biometrics could be used to determine user emotions.
• Mouse devices with hand grip detection, to determine frustration.
• Cameras which monitor facial reactions.
• Language used during text interaction with the avatar.

The last point certainly seems valid.  What would this be useful for though?  FAQ type systems?  Could you possibly drive site navigation via a keyword driven avatar, returning differing results depending on gauged emotions?

My thoughts with current technology are that outwith user inputs such as direct textual conversation, it is hard to gauge emotion.  I do think though that some form of rules engine could be developed to determine emotions and react to the user in different ways.  For example if the user exhibits some form of navigation pattern while using a website, which indicates that they might be lost, perhaps an avatar would help negate negative emotions, and if it successfully helps them find where they need to go, perhaps their mood may then even be positive.  Or, what if the user is found to be on a checkout process for some time, perhaps an avatar could be injected onto the page to provide assistance.

Regardless, I think relying upon hardware for now, is a non starter.  Perhaps as devices become more camera ready ( mobile is certainly miles ahead of desktops currently), then detecting facial emotions might not be so far away.  There is a big assumption of course that people will want their devices monitoring them, which I think is very unlikely to be a given, for many obvious reasons.

There is serious potential though for emotional avatars.  I’m still unsure where though.  The world certainly could do without another Microsoft Clippy that’s for sure!  With some thought though and making use of behavioural interaction modules that new content management systems are now beginning to make available, I think there could be room for these emotional avatars to build empathic relationships with users.

Thanks for reading.

Summary

Often when a site is designed, developers will set the outline for navigation elements to none, or zero.  Effectively this means that when you try to navigate a website using a keyboard, visually you will have no idea where you are on the page which most often than not forces user to use a mouse.  This is fine until a user becomes dependent upon the keyboard for navigation – such users, who cannot use a mouse suddenly become severely impacted by the pages inability to highlight what they are currently navigating through.  Of course it’s not just an accessibility flaw, some people just like to use the keyboard to quickly navigate items.

Example of a link outline appearing when the user navigates links using their keyboard.

Why do people remove it?

Some people just hate the sight of a link outline.  Much like how visited links are often styled to be the same colour as non visited links to the detriment of accessibility and usability, simply to appease a design – the good old link outline can often suffer the same fate.

Interactive elements controlled using Javascript and styled for example as oversized fancy call to actions are often the first to suffer, as 99% of the time these controls are just link anchors styled and controlled using JavaScript to appear all fancy and interactive.   If the developer hasn’t already removed the link outline, you can guarantee that when someone sees the outline around their beautiful call to action, a complaint that it doesn’t look very nice will follow.   The outline will likely later be removed, without a suitable keyboard accessible alternative put in place.

Applying and removing link outlines

Outline can be applied using the CSS :focus selector on a targeted HTML element like below:

a:focus { outline: 1px dotted; }
selector:pseudo-class { propery:value; }

This declaration essentially says that for all link anchors (a tags) when they have focus, apply the property outline with a width of 1px, dotted.

a:focus { outline: 0; }

The above will have the reverse effect, by removing the link outline for all anchors.  This now impacts keyboard accessibility.

So what if I still don’t want to apply a link outline?

Not setting an outline is fine, as long as you can provide an alternative style for it.  The main objective is to provide keyboard accessibility here, so as long as you have a suitable alternative accessibility will not be impacted.

Rather than using a link outline, perhaps changing the text colour when the link is in focus would be a suitable alternative.

Example of outline removed with the text colour change replacing it when the link is in focus..

This can be easily achieved with a little tweak to your CSS:

a { text-decoration: none;}

a:focus { outline: 0; text-decoration: underline; color: red;}

So now we are essentially telling anchors which don’t have focus to not underline their text (text decoration = none).  Anchors with focus now also have their outline removed and instead have their text underlined and in red.  Very simple and design wise and probably an improvement for visual indication of an item in focus.

As long as you maintain a good colour contrast for alternative styles when you choose to not use outline for elements in focus and keep a decent level of consistency in terms of colour choices, then accessibility should not be impacted.

Is that it?

As long as you ensure that all interactive and navigation elements on a page have a focus effect applied for keyboard navigation then you should be fine.  A good rule of thumb to use for this would be checking if anything with a hover (mouse over) effect, also has an equivalent keyboard accessible focus effect.  Manual inspection would still be required though, to make sure nothing was missed that didn’t have either a hover or focus effect.

Compatibility issues with older browsers

Now is probably a good point to highlight the issues that will arise with solely relying upon the CSS :focus selector to apply highlighting for items in focus.  On older versions of Internet Explorer (IE), the :focus selector wasn’t supported, so to get around this we use another selector :active.  Active will allow you to style currently active elements on IE6 and 7, but for IE7 it will only work on anchor elements (links).

If you don’t want to be limited in IE7 to anchors, you can make use of a JavaScript library called IE7-js (actually a series of library’s for IE7-9), which will allow you to make use of the: active selector on other elements just by loading the library via a conditional statement in your document.  If you want to go one step further and don’t need to support IE6, you can ignore :active and gain support for the :focus selector in IE7 by including IE8.js in your conditional statement.

How do I test for this?

The simplest test would be to check page navigation with the keyboards tab key, to check if an outline or alternative style is applied around the element in focus.  If it doesn’t, then this means a style has not been considered for keyboard navigation.

Another quick test would be to open developer tools (F12 on most browsers) while viewing the web page and inspecting the sites style-sheets.   A good rule of thumb here, is that any declaration that has :hover set on a selector, should also have both :focus and :active equivalents.

Example of a good declaration, which includes :active and :focus for keyboard navigation styles.

Sometimes though, poor markup implementations affect your ability to target elements for styling. This usually occurs when non standard markup is used for interactive elements in combination with JavaScript event handlers such as onclick to provide some form of interactivity e.g. onclick="window.open('http://www.someurl.com')" (on selection, open in a new browser window this URL). So it is always important to go over navigation elements with a fine comb to weed out anything you may have missed.

The last test is actually an oddity which is rarely done.  Sometimes HTML elements on a page which would not normally be included in the keyboard navigation cycle are forced to be included by assigning the tabindex attribute.  There may be a good reason for doing so, but I’ve yet to see one.  Normally depending upon how your stylesheet has been configure for elements, these items would be excluded from keyboard accessible visual indicators such a outline.  Unless you can justify a good reason for them to be included in the tabindex, I would normally suggest removing them.  Every browser worth testing these days automatically indexes HTML elements which should be included in the tab order, so taking over its control to include non standard elements often impacts accessibility, so be careful.

Thanks for reading.