Extra information (mother’s maiden name/age at death/spouse surname etc) on the Results page

[KristinaGadzhieva]

To put extra information (mother’s maiden name/age at death/spouse surname etc) in a separate table column on the Results page.

[richardofsussex]

Implemented:

[richardofsussex]

This is now on test3

[AlOneill]

I'm going to assume that the clash with the advertisement above needs no further comment.

However, this is what I see when I start a new search and then reduce the screen width so that the hamburger menu appears:

[richardofsussex]

Where are we at with this issue? What needs to be done/fixed?

[KristinaGadzhieva]

I don't see the changes related to this story on test 3. There is no information in the column (MMN, AAD, SS).

[richardofsussex]

There is for me: (The heading doesn't change if you apply a filter to the results, but I think that we can let that one go.)

[KristinaGadzhieva]

In the description of this story: To put extra information (mother’s maiden name/age at death/spouse surname etc) in a separate table column on the Results page. But there is no information in this column on test 3.

[richardofsussex]

That's probably because you're looking at older records which lack this information:

[KristinaGadzhieva]

Right. I was looking for Josephine Smith, from 1837 to 1905

[AlOneill]

@richardofsussex How will a user know what the column heading ‘MMN/AAD/SS’ means?

[AlOneill]

@richardofsussex I appreciate that this is a work-in-progress, but it seems that there are some existing problems as well as new ones with this table.

I've listened to the table on a screen reader. It took me 9 or 10 presses (I lost count) to get through the info in the second column (but perhaps I'm not using the best method to hear the contents of that cell?). I do not think the description list is the best way of marking up the information in that column: for a start there are lots of terms, dt, but no definitions, dd. It seems that the list has simply been used to get separate lines without the need for a break element!

The caption describes three columns, not four. (This is read to a screen reader user.)

Again, there is no help with understanding the meaning of the heading of the third column.

[richardofsussex]

What HTML markup would you recommend to achieve the layout we currently see? Or would you advise going to something more like the FreeREG and FreeCEN results tables, with a column for each item of information?

The caption issue is easily fixed.

As regards 'MMN/AAD/SS', we are obviously trying to avoid an enormous column heading. We could put 'Mother's maiden name/Age at death/Spouse's surname' which would remove your problem. Is there another technique we can use with HTML that would allow us to keep the abbreviated heading but would be screen-reader-friendly?

[AlOneill]

@richardofsussex Suggest using <br> — it’s what it’s for. Increasing the number of columns would impact responsive behaviour.

It is not my problem. It’s an issue for most users (unless they are mind readers). Not just for screen reader users either. For the latter group, an explanation in the caption is probably enough. For everyone else, I suggest a note ahead of the table (which would most likely be missed by screen reader users).

[KristinaGadzhieva]

To discuss with the Steering group

[richardofsussex]

Results table layout changed as requested and explanations added/updated: see fb_582_rbl. @Vino-S please add this code to beta.

[AlOneill]

Maybe I'm jumping the gun, but I'm getting this for the caption of a 4-column table: "Column 1 has link to details of record; Column 2 can be sorted on First Name; Column 3 can be sorted by event."

I do see "Mother's maiden name" for the heading for column 3 where I searched for births; "Age at death" for deaths; "AAD/SS" for marriages and deaths, with no explanation of the abbreviations.

[richardofsussex]

You are indeed jumping the gun - @Vino-S has not yet had chance to move my changes to beta.

[richardofsussex]

Have a look now ...

[AlOneill]

Thanks! I can see the changes now … doh!

I'm thinking that vol # and page # are superfluous in the results table and would be better saved for details page (as unlikely to affect a user's initial judgement of a result).

Also h1 is in the wrong place: should be before form controls at least.

The links group (nice one) would be better marked up in a nav element with an ARIA label to distinguish it from other nav blocks.

{I am done in so will stop for now … thoughts on caption to follow)

[AlOneill]

Some more thoughts: The first link in the top group, to View Search Criteria is invalid, so the Criteria appear but the focus does not move and the next press of the Tab key goes to New Search, the second link in the top group. It takes 5 presses of Tab for the user to arrive at the close (X) button. Not cool.

The interesting info that there are however many results is lurking in an anonymous div that a screen reader user is unlikely to find — how about combining it with the h1 and making the resulting h1 visible? (Unless there are scrolling police on BMD.) It might not be obvious to all users where they are, especially if they have been timed out on their initial search.

I'm not yet sure how to deal with the level 4 heading being before the level 1 heading. The obvious thing to do is to put the level 1 heading ahead of the Search criteria. And then make the hidden level 4 heading a level 2. Maybe make the search criteria box an aside that is labelled by the level 2 heading.

Thoughts on caption still to follow … it's tricky …

[AlOneill]

Back to the caption and related matters:

The setup seems quite complicated in that, in order to sort or apply a filter, a screen reader user is required to navigate from the table to the form and then back to the table, each time going via the rotor, probably. Altogether, quite a lot of faff. And most of the faff is understandable — we offer to sort on several criteria that do not have their own column. However, it does seem unfair on SR users. And it makes for a long caption, explaining not only the structure of the table but also how to sort or filter the results.

The obvious alternative would be to put each of the sortable items in their own column and put buttons in the table header cells to do the sorting. This could make problems for mobile-size screens. I seem to remember that REG solved this by using a description list on mobile screens (and using device-sniffing to decide whether to supply a table or a dl). I cannot remember whether they managed to keep the sorting in the dl. This (adding more columns) would not be an easy decision.

Some experimentation will be needed, whatever is decided. There is more information on: https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/sortable-table/

[richardofsussex]

OK, I have implemented a multi-column strategy for consideration. This still groups some data within a single cell (forename/surname; district/volume/page) but the result is, I think, entirely reasonable in terms of number of columns in the table. Mother's maiden name, age at death and spouse's surname columns only appear if that event type formed part of the original search. These columns are also sortable, offering new functionality to our users, e.g.:

[richardofsussex]

The name links need to look like links - in fact all the links lack an underscore.

I would question whether there is any practical value in the type of event filter, given that users can easily adjust this by updating their search and re-running it (or by asking for what they want in the first place!).

[DeniseColbert]

Waiting for this to be added to Test 2 so we can consider this 'new' layout

[richardofsussex]

Headings and links adjusted as requested:

[Vino-S]

The new layout is in test2

[DeniseColbert]

Thanks Vino. Is everyone happy with this new layout?

[AlOneill]

On a screen less than about 865px wide, the advertisement begins to lie on top of the table, like so:

Will check on mobile phone later.

[AlOneill]

At around 600px wide the table is getting clipped widthways (it does not scroll: see REG for the container needed to make such tables scroll):

[richardofsussex]

Responsiveness of the search results table is a separate issue (albeit one which has been surfaced by the table being wider). I have created a new issue #593 to address it.