Link

Technical Reports page - version 4


Version 4 prototype of the Technical Reports page has been deployed and contains a number of iterations following feedback from the W3C team.

View the Technical reports (TR) v4: default and the Technical reports (TR) v4: search results pages.

Below is a summary of the main feedback and our responses:

  1. How can we best help new users understand how to search on this page? The ‘not sure where to start’ content has been brought further up the page into the search box so it has more visibility, and we have added ‘hint text’ to suggest to users what they can search for. We have also updated the microcopy in various places to better guide page users.
  2. The visual balance of the page was addressed, to make content easier to scan and the search box stand out more. There is still a general consideration that there is too much padding / white space on the page, however we will address this once we have more real content across all the template types. Then we can review spacing holistically and make adjustments.
  3. We have been given feedback that there is not enough colour on the page. However we advise against adding colour just for the sake of it - this doesn’t help users find information. Firstly it gives users more information to try to decode (what do the different colours mean? How do we explain what they mean?). Secondly if we added more colour we’d need to review how that works with the rest of the site.
  4. Should we restore the history link for each specification? Our recommendation is to keep the history link off the TR listing page to reduce content and keep it to the most important information for users. This enables scannability and saves space. Keeping the history link on the specification headers instead would be a better place for it to sit.
  5. Should we add focus on the search box so users can start typing directly? No, we don’t recommend this. The search field is an important feature and purpose of this page. If the user is visiting the page with the expressed intention of searching, then autofocusing makes sense, however, for all other intentions, it would get in the way. I’m currently not convinced that adding autofocus would help more than it would prevent people from browsing the list of reports. Additional reference: https://webaim.org/blog/future-web-accessibility-html5-input-extensions/
  6. Can the page refresh the results as you type as on the current /TR page? We strongly recommend against refresh-as-you-type. Reference: https://www.w3.org/WAI/WCAG21/Understanding/on-input.html
  7. Having the filters collapsed by default makes them harder to find - can they be expanded. Does having the filters collapsed make it harder to find? Yes. But does it make it too hard to find? We don’t think so. We are recommending a balance between allowing user to search quickly and see results vs giving options for users to filter results further if needed. (Opening filters would mean more scrolling to see results).
  8. Can you make the family name sticky while scrolling, as if a family contains a lot of documents, it’s easy to lose the context? We recommend against this because the most common issue with making stuff sticky is that it can obscure other content. Some people use the TAB key to navigate web pages by moving through focusable elements (e.g. links, buttons, inputs). They can use the SHIFT + TAB key combo to move backwards through those same elements, and in this situation sticky elements can obscure a focused element, which is not good for accessibility.