Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unique names for people... page - reconsider presentation of the results #608

Open
nurifreembd opened this issue Nov 26, 2024 · 26 comments
Open
Assignees
Labels
ready for deployment ready to be rolled out to live. Records page

Comments

@nurifreembd
Copy link
Collaborator

Current presentation of names are to busy and not vey user friendly. we could consider tabular form.

example below:

A

Atelle  Aud L  A  A Danneskjold  A E  A I  A M  Aaron  Aaron Charles  Aaron D  Aaron George  Aaron H  Aaron John  Aaron M  Aart  Aart W  Aart W V  Aase J  Abal G  Abal G K  Aban J  Abbey  Abby  Abby B  Abdul H  Abdul H R T  Abdul H R T M  Abdul R S  Abe A  Abe Thomas  Abel  Abel Bunting  Abel Edward  Abel G  Abel George  Abel H  Abel John  Abel S  Abel William  Abel Willie  Abergail  Abetha R  Abgail Boughton  Abi Joan  Abigail  Abigail Bedford  Abigail Boughton  Abigail Eliza  Abigail Eugenia C  Abigail Martha  Abijah  Abina  Abitha  Abither  Abner  Abner Frank  Abney A G  Abra F A  Abraham  Abraham A  Abraham Arthur  Abraham Austin  Abraham C  Abraham Chambers  Abraham Charles  Abraham Denby  Abraham E  Abraham Frank  Abraham Hirst  Abraham J  Abraham J E  Abraham James  Abraham John  Abraham M M  Abraham Robert  Abraham Thomas  Abraham W  Abraham William  Abram  Abram E  Abram F  Abram Scott  Abram

@AlOneill
Copy link
Collaborator

Unless the names are marked up individually as list-items, within a list, they are pretty much inaccessible to a screen reader users. The current markup is in an unbroken (no separating punctuation even) block within a paragraph). The whole paragraph is announced together without a sense of where one name ends and the next begins, and with no means to pause or review the names. Using list-items would enable a screen reader user to hear each name as a discrete entity, to pause the reading and to hear a name again, and even to hear the individual letters.

FreeCEN is using lists AFAIK.

A table would not be appropriate.

@nurifreembd
Copy link
Collaborator Author

Is lists AFAIK different to the current presentation?

@AlOneill
Copy link
Collaborator

@nurifreembd
I do not understand your question — unless it is AFAIK (= as far as I know) that I need to explain? Apologies for using the abbreviation and for not putting a comma after lists. I.e. "FreeCEN is using lists and list-items, as far as I know."

I believe that REG is still dumping the names in a paragraph, much the same as BMD. Which is why I said: The current markup is in an unbroken block (with no punctuation) within paragraph tags.

@richardofsussex
Copy link

I've just checked, and neither FreeCEN nor FreeREG is using lists. They both dump all the names into a <p> element, with &emsp;&nbsp; between names. I would agree with the sense of using list markup to help screen readers make sense of the content. However I would also question whether any practical use can/could be made by users of the humungous lists of names which FreeBMD generates. The lists produced by the other two projects are much shorter, and so are likely to be of more use.

@AlOneill
Copy link
Collaborator

Unless Ann has reverted the code, CEN is using lists for its Records section.

@richardofsussex
Copy link

I think we're both right :
image

@AlOneill
Copy link
Collaborator

@richardofsussex
If we offer the names, then they should be accessible to all users. Have you listened to the names dumped in a paragraph with Narrator?

I'll have a look at how the blocks relate to each other — maybe we could offer a more sensible size?

BTW, those fieldsets and legends are not being used properly — they are only for forms — if they are being used like on BMD, we have to get rid. Used like that, screen readers are likely to be confused. (Is there no end to dodgy markup??)

@richardofsussex
Copy link

If we offer the names, then they should be accessible to all users.

I strongly agree, but I think the first question to ask is whether anyone would find these massive lists of names useful as they stand, and if so how/why. I would have thought that some sort of filtering would improve the signal to noise ratio - type in a sequence of characters and see all names containing that sequence.

BTW, the BMD markup doesn't use fieldset or legend, so that's one less thing to worry about.

@richardofsussex
Copy link

I've attempted the minimum on this page - keep it looking more or less the same, but using <div> with a suitable heading followed by a <ul> with the list items displayed along the line rather than vertically. @Vino-S will comment here when it's deployed for testing.

@KristinaGadzhieva
Copy link
Collaborator

Implemented on Beta. @AlOneill could you please have a look ? https://beta.freebmd.org.uk/districts/201/unique_names?locale=en&name_type=1&record_type=birth

@AlOneill
Copy link
Collaborator

Markup works well for a screen reader user. Except for the number of names!

For a sighted user, the vertical presentation of each name is a bit odd — I did not understand it until firing up VoiceOver. How do we see the names that are initially off the screen (to the right)? We have a class that puts a list inline, but I now cannot find a list of names on CEN that uses that class, only names dumped in paragraphs — I thought we had fixed that issue, sigh.

One listing per district gives far too many names. We need to consider breaking it down somehow — by decade? by century? by ??

@richardofsussex
Copy link

This could be a rare example where assistive technology users get a more complete picture than sighted users! My initial goal was to stop these pages from being an accessibility nightmare - it sounds as though I have achieved that goal. (Would it be helpful to provide A-Z links at the top of the page, to allow the user to jump to a specific letter?)

I didn't know about our 'inline list' class, so did the usual trick of finding CSS techniques on the web and slavishly copying them. I've had two goes at this and clearly got it wrong both times. If we can track down our class I would be delighted to use it.

We're in total agreement about there being too many names. It's an approach which works well e.g. in REG with parishes - not so with a Registration District. I have just been looking on the BMD1 site, and I don't see a corresponding page on there. Presumably we decided to include this as a new feature for BMD because it appears on REG and CEN?

I would suggest adding an autocomplete box at the top of the page, so that the user can be shown all names containing the characters they type in.

@AlOneill
Copy link
Collaborator

AlOneill commented Jan 22, 2025

@richardofsussex
I've found the class name: <ol class="nav"> — kind of obvious when I think about it (doh).
We used an ol because the names are sorted alphabetically.

If that alone does not make the list accessible to sighted users, then I'll take another look.

Yes, some navigation by initial letter would be good: on CEN we set it up like this:

<nav aria-labelledby="names_nav">
     <a class="push-half--sides" href="#names_A">A</a>
     <a class="push-half--sides" href="#names_B">B</a>

After each list, we used a back-to-the-navigation link, thus:
<p><a href="#names_nav">Choose another letter</a></p>

Not the best way, but it was a while ago and I was under pressure to devise something quickly. An ordered list with the class nav would again be more appropriate. The class of push-half--sides was needed to allow for fat fingers on a touch screen: it might not be needed with a nav list.

I think you are correct: the names listing is borrowed from REG and CEN. I am disappointed that CEN seems to have reverted to a paragraph dump.

An autocomplete box would help some users (but not screen reader users unless we can work out how to set up an alert successfully). As does the browser Find function.

@AlOneill
Copy link
Collaborator

By the way, 'unique' is not used here in the same way as in everyday English. It bothers me. Does it bother anyone else?

@richardofsussex
Copy link

Thanks for tracking down the CSS classes to use.

Yes, I think we're intending to drop 'unique' from the description.

@DeniseColbert
Copy link

DeniseColbert commented Jan 22, 2025

Yes, unique is legacy language, and there is a current story to remove it.

A small observation re. autosuggest: while it could be good for some ways of using the names section, I think it's the what we can tell about the data by browsing that makes it so powerful. Admittedly, that browsing is torturous for screen reader users, but This is an accessibiity problem that can be addressed post-MVP, I think. Additionally, if the misspelling or special character is near the start of the name, for instance, it wouldn't really help.

@richardofsussex
Copy link

See beta now - thank you @AlOneill for the CSS class. I think the page is now usable by all users.

One idea is that we could provide a 'filter' facility, whereby the user types in a name or part name and submits the form, causing the page to refresh showing only the names which match their filter. If we're using the Rails regex capability this filtering could be quite powerful.

@KristinaGadzhieva
Copy link
Collaborator

I support the suggestion for filtering. The amount of information on the page is difficult to read. However, we need to weigh the time costs of this.

@richardofsussex
Copy link

Time costs are not too great - draft code is with @Vino-S ready to push to beta.

@richardofsussex
Copy link

richardofsussex commented Jan 23, 2025

Now in beta, e.g. https://beta.freebmd.org.uk/districts/201/unique_names?record_type=birth&filter=Jonath%5Bao%5Dn&button=#names_nav shows variant spelling of 'Jonathan'. Please test - I got an empty result for the first filter I tried.

(Note that the filter 'Jonath.n' has the same effect.)

@AlOneill
Copy link
Collaborator

@richardofsussex
The filter seems to work as expected — nice one. However, there are some issues with the look of the page that need fixing.

The alignment, both horizontal and vertical, is off and this affects both the main menu and the logo placement (not shown below):

Xnip2025-01-24_12-05-17.jpg

I hope you can see this image as it would be too difficult to explain it all in words! I suggest you look closely at the main menu if you cannot see my image.

The other issue is that we do not need all the "Choose another letter" links on a page of filtered results — they look naff.

@AlOneill
Copy link
Collaborator

@richardofsussex
We get the extra links when filtering without the initial letter.

@richardofsussex
Copy link

Check beta now: I have made various improvements to layout and content.

@DeniseColbert
Copy link

Should we have a message when there are no names found with the inputted characters?

@nurifreembd
Copy link
Collaborator Author

nurifreembd commented Jan 28, 2025 via email

@richardofsussex
Copy link

Code updated; @Vino-S to push it to beta, please.

(There is an unresolved issue with case-matching in the RegEx pattern. Sometimes - but not always - you have to put the match string in upper case to get the desired set of names. There is now some temporary wording to warn users of this, but @Vino-S and I will need to get to the bottom of this issue prior to release.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for deployment ready to be rolled out to live. Records page
Projects
None yet
Development

No branches or pull requests

6 participants