Header - Development of new Header Organism

[jinky32]

This issue discusses the code to be developed for the new Three header. Other elements related to the footer (for example Site Builder editable regions etc) can be found in the tech brief. Please contact Stuart Brown if you need a copy of this.

The look and feel of the headers is below

We are seeking advice on accessibility requirements for this header. Some issues to be considered may be:

• Use of
  tag and whether ARIA role="navigation" is implied within the HTML5 semantics.
• Provision of 'skip to content' link.
• Accessible markup for the search field
• An accessible way to implement the toggle between searching the Three website and searching the web through Google.
• Advice and suggestions regarding accessibility on the responsive navigation.

Please leave feedback in the comments below.

[ajgarrison]

Hi,

1) With regard to WAI-ARIA role="navigation", this should be implied through the HTML5 <nav...> element. Due to the growing, but not overall, support for this element it is still wise to give it a <...role="navigation"...> attribute e.g.

<nav role="navigation">

2) Ideally a "skip to content" link should always be provided e.g.

<a href=”#main”>Skip to Main Content</a> <div>Navigation goes here</div> <div id=”main” tabindex=”-1”>  <p>Main content goes here</p>  <a href=”#”>a link in the main body</a> </div>

Or if you use the newer HTML5 elements

<a href=”#main”>Skip to Main Content</a> <nav>Navigation goes here</nav> <main id=”main” tabindex=”-1”>  <p>Main content goes here</p>  <a href=”#”>a link in the main body</a> </main>

This skip link can be hidden visually off-screen (e.g. preferably using the clip technique - http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content), but should become visible when focused using the keyboard - see https://www.bignerdranch.com/blog/web-accessibility-skip-navigation-links/ for a clear explanation.

3 + 4) The real question is about the auto-complete function. It's not the technical accessibility (they can be made - see https://www.marcozehe.de/2014/03/11/easy-aria-tip-7-use-listbox-and-option-roles-when-constructing-autocomplete-lists/), rather the user experience for a screen-reader user that is the issue.

My thoughts would be to not worry about the accessibility of the auto-complete function for screen-reader users, making sure however that all dynamic content changes are done after the search box. This way a screen-reader user is unaware, and "un-nuisanced", by the dynamic content changes occurring below - they simply experience a clear search box to type into and then a search button to press.

You will, however, need to ensure that the options which become available below the search box are keyboard accessible - like the current search box on http://www.three.co.uk/.

In fact, looking at the current search box on http://www.three.co.uk we would suggest a few minor changes i.e.

<form id="main-search-form" class="device-width-content" method="get" action="//www.three.co.uk/static/search.htm"> <fieldset> <legend class="hiddenOffscreen">Search categories</legend> <input type="radio" id="search-three" class="a11y-hide-away" value="//www.three.co.uk/static/search.htm" data-placeholder="Three" name="search-type" checked="checked"> <label for="search-three">Three.</label> <input type="radio" id="search-web" class="a11y-hide-away" value="http://mybroadband.three.co.uk/dashboardlaunchlink/static/html/mobile_broadband_dongle_login/search_results.html" data-placeholder="the Web" name="search-type"> <label for="search-web">Web.</label> </fieldset> <div id="searchThree" class="initiallyShown"> <label for="search-query" class="hiddenOffscreen">Search Three:</label> <input type="search" id="search-query" class=" naked" name="q" placeholder="Search Three..."> </div> <div id="searchWeb" class="initiallyHidden"> <!-- initially hidden using CSS display:none, and swapped --> <img src="/static/images/powered_by_google.jpg" alt="Powered by Google"> <label for="search-query" class="hiddenOffscreen">Search the web:</label> <input type="search" id="search-query" class=" naked" name="q" placeholder="Search Three..."> </div> <button type="submit">Search</button> </form>

Note the addition of a <legend...> element which can be hidden off-screen if necessary, and the removal of the second <fieldset...> element. Also, we've changed the <...type="..."...> attribute to "search", rather than "text" - just to define the input a bit more.

Noting, the selection of "Three" or "The web" dynamically shows and hides the relevant content in the two added <div...> elements.

5) With regard to the accessibility of the responsive navigation, you don't seem to be making the same choice between searching "Three" and "The Web". If its only "Three" we would recommend using the following:

<label for="search-query" class="hiddenOffscreen">Search Three:</label> <input type="search" id="search-query" class=" naked" name="q" placeholder="Search Three..."> <button type="submit">Search</button>

Although, ensuring that the "Search" button is large enough to be pushed with a finger - some people recommend at least 44px x 44px.

Otherwise, we would suggest placing the content under the search box in a <nav...> element e.g.

<nav role="navigation"> <ul> <li>Home.</li> <li>Store.</li> etc... </ul> </nav>

Hope this helps.

Alistair Garrison On behalf of the Digital Accessibility Centre

[jinky32]

@ajgarrison my email to to you bounced so posting below:

I’ve created a header feature branch https://github.com/ThreeUK/digital-library.three.co.uk/tree/header – the header html is at https://github.com/ThreeUK/digital-library.three.co.uk/blob/header/source/_patterns/01-molecules/00-header/01-header%40inprogress.mustache. Please note that this is an early cut of the HTML and Niall (our developer) is on leave this week and may well have made alterations. Regardless it would be great if you could commit changes to this header branch and we can take things form there.

As you may be aware we are using http://patternlab.io/ to document / demonstrate the emerging Digital Library at http://dedi.three.hostedservice.net/digital-library/public/index.html which hopefully helps explain the file structure within the repo.

I have a copy on my own hosting http://www.stuartbrown.name/three/header-footer/hf.html so you can see it with styling applied (same caveat about code maybe slightly out of date!).

[DigitalAccessibilityCentre]

@jinky32 I have updated Alistair's email addy, apologies for the bounce back. All should be sorted now though.

[ajgarrison]

I had a chance to make a few changes to the file - https://github.com/ThreeUK/digital-library.three.co.uk/compare/header...ajgarrison:patch-1

Let me know if this is ok, or if you need me to do anything further e.g. commit changes.

All the best

Alistair

[papafed]

We need to see if we have enough control over the autocomplete thing, because all that code is generated by Google.

note to self - need to revise search input (and any others with multiple controls) in both this header and the consistent forms to use fieldset container instead of label, and use the labels[for] method of control association. Must make it consistent with checkboxes and radios without adversely affecting either.

[jinky32]

@DigitalAccessibilityCentre @ajgarrison We are adding 'register' and 'login' links to the header. Are there any ARIA roles / other accessibility features that we should consider around these links?

[GavinAEvans]

The only thing I would consider adding is role="banner" please see: http://www.w3.org/TR/wai-aria/roles#banner