Inform users if an entry has a not typical page number

[KristinaGadzhieva]

To provide a textual description if an entry has a page number which is not typical for the district. Analyze cases where a district is shown in italics on FreeBMD1.

[richardofsussex]

An italicised District happens when the distSusp flag is set:

This flag can be set when one or more of the following applies:

• the District name is misspelt
• the District doesn't exist/has been invented
• the Volume number doesn't match the expected values for that District and Quarter/Year
• the District cited didn't exist during the specified Quarter/Year
• the Page number doesn't match the expected values for that District and Quarter/Year

[richardofsussex]

These are the messages currently associated with each of these error conditions:

[richardofsussex]

This information clearly needs to go on the Entry Information page. I suggest we start by implementing that.

At present Districts are italicised in the Results page if their distSusp flag is set. There are three reasons I can think of for reconsidering this approach:

• an italicised entry is not accessible, and should be replaced by an accessible way of conveying this information
• calculating the distSusp value for each record in the Results page may be computationally expensive, i.e. may slow down the generation of this page. (We will have a better idea about this after implementing support in the Entry Information page.)
• two of the queries are not about the District itself, but are instead about volume or page number ranges

On further investigation, the 'suspect district' information is packaged into the DistrictFlag field. If it is not zero, there is an issue to report (not necessarily with the District itself). So putting an indicator like a 'dagger' symbol in each result page entry would provide the same information as the italicisation does, in BMD1.

[richardofsussex]

Queries about the District, Volume and Page should be added to the appropriate cell in the Entry Information page table. They could be complemented by a textual description, based on those found in BMD1 if you follow a link to a questionable district.

[richardofsussex]

I've implemented this as a dagger symbol linking to an appropriate footnote below the Entry Information table:

[AlOneill]

@richardofsussex
Unfortunately, the dagger symbol is not in the list of charactrers that we can safely assume will be announced by screen readers. An image of a dagger, with appropriate alt text would be announced.

See Why Don’t Screen Readers Always Read What’s on the Screen? Part 1: Punctuation and Typographic Symbols and scroll down to "Safe Characters (all screen readers read the characters out loud)". And then read the following section, "Unread Characters (meaning that at least one screen reader will not read the character out loud)". In fact the whole page has a lot of relevant information. (Although the article was written in 2014, screen reader development proceeds relatively slowly and many relevant institutions do not have the resources to update them in a timely way.)

Also, information that comes after the link is likely to be overlooked by a screen reader user who has already followed the link and it will not appear in the links listing for that page. I'm thinking that placing the symbol before the link or better still making it part of the link would be more helpful.

[richardofsussex]

If instead I put an <a href=...> link with the text "See note" and a target pointing to the note further down the page, would that work for a screen reader?

[AlOneill]

@richardofsussex
Sorry, but no. That link would be meaningless out of the context of the page (in a list of links). It is a cousin of "click here".

Mind you, on reflection, a simple number is not really helpful. The link needs to be "Page 123", with "Page" in a span with class="accessibility" so it is read out to screen reader users but not visible. (This is a weakness of putting information in a table where that information is not really table data to begin with.)

Similarly, "Oldham" (in this case) would need "District" in an equivalent span, plus anything else that makes no sense out of context. Sorry.

[richardofsussex]

The code is now on test3 for review. I think it could be improved, for example:

could include information on what the expected page range is.

[richardofsussex]

Following discussion with Jason, we think that the qualification in the Entry Information page should be placed in the relevant table cell when the query is specific to one item of data (e.g. the District name), and placed in a separate note under the whole table when it could be any one of a number of data items which is actually suspect/wrong.

Our initial instinct is not to put any indication that a District (etc.) is 'suspect' in the Results page entries. The alternative would be to include a textual note saying, e.g. 'Suspect data: see Entry information page for details'.

[DeniseColbert]

@AlOneill do you have any input on this approach?

[AlOneill]

@DeniseColbert @richardofsussex
I am concerned that for those who cannot see the page, how will they realise that there is a note after the table? Will there be something in the possibly affected cells? Or will the h1, for instance, be modified in such cases to point to the additional information? Or something equally obvious?

[richardofsussex]

See the beta site for an updated strategy which I hope will meet accessibility requirements.

[AlOneill]

When I listen to the table row for the page number I hear:
"page", "link, 230, dagger" but I have no idea what to do with the information that there is a dagger.
For a screen reader user to find the note marked by the dagger, I suggest that the dagger in the table cell needs to be a link to the footnote. I suggest that there should be some text with class="accessibility" as part of the dagger link, saying something like "further information in footnote".

[richardofsussex]

@Vino-S is looking into it, but the code I submitted doesn't have any daggers in it, and does indeed contain text with class="accessibility". We'll let you know when beta has been correctly updated, so you can check what I actually wrote.

[richardofsussex]

Try beta now. The code isn't perfect, but at least you can see the idea I am trying to implement. (Look for Jane Partington, Sep 1837 - Dec 1845, volume 20 page 181 as an example.)

[AlOneill]

@richardofsussex
Yes, that is a step forward. As you say, not yet perfect — the link '[district query]' goes nowhere, for example. Also, telling a user that "We are afraid, we do not have this information yet" for a Mothers Surname in 1840 is rather misleading — leaving the cell blank is probably better, but better still would be to not render an empty row or to say something like "this was not recorded until [insert date here]".

I've been thinking some more about the awkwardness of the filter and sort for SR users and how that would impact the caption.

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, because the how is not obvious if you cannot see the page.

One 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 or not a user is able to sort the description list on REG, but I suspect not. Adding more columns would not be an easy decision.

Food for thought.

[richardofsussex]

I've just updated the code so that the links do work. In the process I have added <div> elements and headings to each type of query. Also just fixed a structure error which was causing the <h2> heading to display at the wrong size.

[richardofsussex]

The filter and sort controls should, I think, be a separate story. I note that the BMD2 project made a decision, some time ago, to go with a single-cell block for the core information of one entry within the Search results table, i.e. to do it differently from the other two projects. So going [back] to one cell per data item [for sortable data] is something of a regression. I'm concerned about us going round in circles and never getting to the finishing line.

[AlOneill]

I'll leave you to fix the layout issues on the Details page. A reminder that all children of .grid need a .grid__item and that all .grid__items need a parent .grid.

Can we try giving the form on the results page an accessible label? I suggest aria-label="sort, show and filter results". I hope that will give a SR user a better idea of what is going on — the browser will not allow me to test the idea! At the moment the individual form controls are listed, with no sense of grouping, including the 'give us feedback' button.

It is only a "regression" (a rather loaded term in everyday English) iff [sic] you believe that those who made the decision fully understood the consequences for SR users.

[richardofsussex]

I'll leave you to fix the layout issues on the Details page. A reminder that all children of .grid need a .grid__item and that all .grid__items need a parent .grid.

@AlOneill do we have any documentation on our CSS grid styles? I see .grid__item's within .grid__item's. Does a .grid__item have to be in an immediate HTML child element of .grid (e.g. <div> within <div>? I looked to the source of FreeREG for guidance, but that's just as much a dog's breakfast as our page!

[richardofsussex]

Presumably we don't use the 'official' CSS Grid framework: https://www.w3schools.com/css/css_grid.asp ?

[AlOneill]

@richardofsussex
AFAIK the only documentation outside of the SCSS files (q.v.) is in Marking up pages in Refinery (available on all three projects, in Refinery, for example: https://test3.freebmd.org.uk/cms/using-refinery/marking-up-pages-in-refinery). Yes, a .grid__item must be an immediate (or direct) child of a .grid — any HTML block will do. And yes, I have failed to convince anyone to fix any of the messes on FreeREG Members' pages. Apparently, members do not care. Except for me and perhaps a couple of others.

Nested .grids and .grid__items should be avoided as far as possible as the results are apt to be unpredictable. However, with care, they can be useful: I recommend the sequence .grid > .grid__item >.grid > .grid__item

Our .grid system is based on floats, explaining why abusing it produces an alignment mess. This is not to be confused with the CSS grid property, which is something completely different. I hope that clarifies the situation, at least a little.