We recently blogged about our new search service. Once we turned off the old search, we started working on creating the global search component and added it to every page on beta.parliament.uk.
This blog post is about what we did from a technical perspective and why.
Designing the search field
Our design team came up with a prototype involving a responsive search bar. On large screens, users would see an input box grouped together with a search button and on smaller screens a clickable search icon that reveals the search bar.
The animation involved two states: the initial appearance of the search icon followed by a revealing swipe of the input.
Making it function
We preferred to have one responsive component rather than two so there's one for smaller viewports and one for larger. Although it’s more challenging on the CSS front, it results in cleaner HTML.
To make this work we use JavaScript to initially check whether the search component exists within the DOM. If the condition’s met, we invoke a ‘checkScreenSize()‘ function that calculates the user’s screen size. The response from this will either add or remove certain HTML attributes which enhance accessibility.
The toggle function itself involves checking whether the search component has the CSS class name ‘.open’. If this statement is true, the ‘removeAttr()’ function is invoked otherwise the ‘setAttr()‘ function is used. These functions are essentially also adding or removing useful attributes.
The ‘.open‘ class applies different CSS property values on the elements within the search component. A change to a CSS property value changes the appearance of an element. By using the transition property, we’re able to achieve an implicit transition (controlled animation involving transitioning between two states).
Accessibility challenges
As a team and with the services of the Digital Accessibility Centre, we focused on making sure that our solutions meet the following basic criteria:
- keyboard compatibility
- good colour contrast
- clean layout and design
- screen reader compatibility
- adequate touch and click areas
- provide adequate feedback
Some principles can be applied via design choices and I’ll be sharing other technical solutions we used to cover outstanding principles.
Larger viewports
The search toggle is not required on large viewports and is hidden from view. This also needs to be hidden from assistive technologies that can identify these type of elements, so using CSS alone was not sufficient.
We also have the undesirable effect whereby the element can be focused on via sequential keyboard navigation (usually with the tab key). By adding the aria attribute ‘hidden’ with an assigned value of ‘true’ and ‘tabindex‘ with a negative value of ‘-1’, this element is unreachable via assistive technologies such as VoiceOver (iOS accessibility tool) and sequential keyboard navigation.
Smaller viewports
In this scenario the toggle is required so tabindex here is removed. We then have two possible scenarios: either the search bar is open or closed. When closed we make sure that the form input field and submit button are hidden and unreachable via sequential keyboard navigation.
We therefore apply tabindex with a negative value of ‘-1’ to the form elements and set aria-hidden to ’true’ to the parent node. Again this prevents assistive technologies highlighting and focusing on this element. During the open state we do the opposite and remove all the attributes set in the closed state.
Icons
Across beta.parliament.uk we use inline scalable vector grapics (SVGs) for our icons. This not only provides greater visual control but results in fewer http requests. You’re also able to express meaning within SVGs by adding titles and descriptions (helpful to assistive technologies). Surrounding our SVGs would be either a link or button element to which we include an aria-label providing context.
As we’re using our SVG icons as re-usable bits of code, the preference is not to provide the title and description within the SVG for assistive technologies. This is because the context can change depending on where the icon is used. Instead a generic title is applied and hidden from the tool using aria-hidden on the SVG tag. This resolves the unfriendly user experience of the SVG being on focus rather than the link or button itself.
Curveballs
Due to variations in viewports, we’re very likely to come across a tricky scenario on a number of devices. The landscape orientation displays the search input as on a large viewport and in portrait orientation as the smaller viewport revealing the toggle.
This is a problem because once the screen gets calculated, the appropriate attributes are applied and by an orientation change we would need the other set of attributes. To solve this we need to use an event listener to detect changes in orientation, after which we can invoke the ‘checkScreenSize()’ function again.
This was an interesting piece of functionality as we had managed to highlight nuances across viewports and tools. Over time, these features will be available across beta.parliament.uk making a consistent experience on the website for everyone. We plan at some stage to blog about performance in relation to the animations used here.
Feedback
We want to be able to gather feedback to help the team learn and make improvements to our services where it counts. So, we need your feedback.
Take a look around beta.parliament.uk and let us know what you think by clicking on the 'give feedback' link on the website, or by leaving a comment below.
Read other posts about the work we're doing to improve parliament.uk.