Change the layout for Check your answers pages

[philsherry]

Previous layouts for Check your answers pages have been table-based.
This isn't tabular data, so tables have no place here. It wasn't the most
accessible solution, or overly mobile-friendly in lots of cases.

This new version ticks several boxes:

• it's far more screen reader-friendly
• it handles text-zoom with less breakage than the tabular version
• screen magnifier users have much less left-right scrolling to do
• improves scalability on mobile devices

Addresses #306

[edwardhorsford]

Hi @philsherry can you include some before and after screenshots?

Agree that the code in the kit is not great. Services that use this pattern generally implement the look and feel, but not using a table based solution.

[philsherry]

Before:

After:

[joelanman]

Hi Phil, thanks for this work. I didn't realise this actually changes the layout for desktop too. Is this intentional? Do we have research to say this is a good change from the current recommended design?

[edwardhorsford]

Hi Phil.

Thanks for attaching the screenshots. I'm not convinced the design pattern needs to change - but the example / code used in the kit should be.

I'm attaching some screenshots from Passports for a more production-like version of this page. We would not expect production services to use a table-based layout to implement the design - it's unfortunate it's in the kit, and we'd like to fix that.

You can see the existing design (really badly documented) handles mobile and text zoom. I'd be interested to hear if you've observed issues with screen magnifier users that would make us want to change the layout - I feel that the linear layout is harder to scan, and on desktop makes the page much longer.

I'm going to try getting an example of a mobile layout added to the service manual, and we'd like to get a better code example added to the prototype kit that demos this.

Passports desktop:

Passports mobile:

[selfthinker]

I have started to work on this before I knew there was a PR. I'm looking into it as part of the Accessibility team, so will concentrate on accessibility.

I created 3 different variants which we are evaluating: using a table (but with a proper thead and a caption and a collapsed version on mobile), a definition list (or rather "description list" how it is now called in HTML5) and an ordered list.

I kept a variant with a table because I think this is tabular data. Although it might not be the most semantic, it is not unsemantic or wrong.
The data is something I would rather paste into Excel than Word. But I can also see how a table might not be needed because you could just use a list (or paragraphs or whatever) with every row just not needing any specific semantics because you could simply write "Name: Value" and it would still make sense because the copy and context is so simple.

While discussing that among the accessibility team it was interesting to learn that some people agreed that it is tabular data, some people disagreed and some people said it's on the edge. It is interesting that there doesn't seem to be a general definition of "tabular data" that everyone agrees on.
When searching for a proper definition I found it hard to find an official one. Instead I found lots of opinions, e.g. a more extensive StackOverflow answer.
A colleague found something in the Techniques for WCAG 2.0 which comes very close to an official definition:

Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal). These relationships are represented in columns and rows, and the columns and rows must be recognizable in order for the logical relationships to be perceived.

Other relevant discussions/articles I found about how to mark up name value pairs:

• http://stackoverflow.com/questions/3281070/semantics-and-structure-of-name-value-pairs
• https://snook.ca/archives/html_and_css/definition-lists-v-tables

The general issue that this pattern uses a table came up multiple times. I wonder if this ever came up because a real user had an issue with. Does anyone know of any such a case? And if yes, what was reported?

[joelanman]

To me the biggest issue is being able to display properly on small screens, as yes, I think it could be argued this is tabular data (labels in one column, values in another, change links in another and the rows are all related groups of information).

Can tables change format to display well on smaller screens?

[selfthinker]

Yes, simple tables like this are easy to make responsive. (Complex or bigger tables is a whole different matter, though.)
I can share my prototype with you privately. It even works on very old mobile devices (tested even on iOS 3 and Android 2).

[philsherry]

Sorry about the massive delay, I've been super busy on some other stuff. To come back to this…

Our service has some long and complicated questions. Fitting them into the suggested pattern just wasn't working out for us. So, while the fake table version might be good for playing back some information, it's not suitable for other information. I think this covers our requirements very well.

[selfthinker]

If you have long and complicated questions, you should ideally not use those verbatim in the page. From the Service Manual:

reword the questions and answers to fit your ‘check your answers’ page - for example, you don’t need to label parts of an address and you can rewrite long questions as shorter statements

In this case e.g. "How do you expect to receive these payments?" could just be "Payment option".

But even if you don't rewrite/shorten the question, it would still look fine in the current table (except on mobile obviously) as long as you don't mix long and short questions and answers.

[etheya]

Bit late to this thread, so will read through more thoroughly as soon as i get chance too but as the designer that created this with Phil i do have a few issues with the current version of the check your answers page. Ive noticed the email thread to that is doing the rounds and i have a big problem with the fact that the information we put in here is in a table. I wouldn't consider this information tabular data at all so im slightly confused as to why we are doing it that way. Even more so that there is a link in there, to CHANGE... that is 200% not tabular data. Also why are we using the full width? I appreciate their appears to be another version pasted above that is only 2/3 which is much better at least from a visual point of view for screen reading.

I understand Phil has mentioned lots of the reasoning and research that has taken place with this pattern and it has had some extensive testing with Chris Moore and Alistair.

I think too that Phil is not saying that this should for example replace the current pattern, but it certainly could be a very good other option. It has tested extremely well in all testing so far, to the point that people dont even notice it, as it does its function without question. Working on all devices, varying abilities of the user and also is extremely accessible.

Will contribute more once i have time to read all the comments and email thread.

[joelanman]

@selfthinker That is true, but there may be some questions here which are hard to shorten and keep clear to the user. If this has tested well with users, that's the main thing.

@etheya we are currently looking into the correct markup - I think @selfthinker is going to update on the other thread: #306

[RossDBrown]

@joelanman @selfthinker Hi both, Ross here - content designer working with Phil and Brian on the service.

Re: Playing back full questions. Yes Joe, this is testing well with users and I've not seen a single user experiencing an issue with seeing the information played back in this format. I've actually been having a few conversations with content colleagues in HMRC about this pattern.

My observations from our UR is that people find it easy to connect with information following this pattern. It's very much a case of 'this is what you were asked, and this is what you answered', and playing it back exactly how it was phrased is helping make this connection.

I also think it's helping those users who do edit by setting their expectations up front. For example when editing "What is your business structure?" users are then presented with a page that asks "What is your business structure?" - so there are absolutely no surprises there.

By contrast, if it were "Business structure: Limited Company" and they edit, what they see doesn't exactly match what they clicked to edit. It's not a wild difference, but any difference at all creates some element of necessary consideration, and associated cognitive load, which I don't think is necessary.

Re: is this tabular data. Personally, I don't think it is - although I acknowledge there are differing opinions being encountered. That said, if we can't agree that if definitely is tabular data I'd lean towards saying we shouldn't treat it that way...

[selfthinker]

Sorry for the long wait. Here is our take on this: #365

[joelanman]

@etheya @RossDBrown @philsherry Hello, continuing the conversation from #365 as I think this is the right thread for it.

We are open to updating patterns based on user research, however we don't always have enough resource to focus on many patterns at once. We're a fairly small team and Check your answers isn't a pattern we're currently looking at.

However, it would be really useful to know more about your research to show that shortening the question didn't test well with your users. Would it be possible to share that information here? Or would another channel be better - you can email me direct on joe.lanman@digital.cabinet-office.gov.uk.

[timpaul]

Thanks everyone for your contributions. We're going to close this PR now. Anika has re-coded the example page to use definition lists and provided classes for short and long questions.

In cases where questions are really long (which hopefully are few and far between) it's possible to over-ride these styles.