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
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).
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.
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.
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.
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.
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.
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.