Open AlOneill opened 2 years ago
@AnneV-Learn Accessibility is a multi-faceted thing and automatic testing will only pick up about 30% of the issues. You have made a commendable attempt!
@AnneV-Learn to take a look and get back to @AlOneill
@AlOneill Sorry this took so long, I got caught up with other issues. I have made corrections (see below) and you can now review on Test3.
Round 1 Corrections:
[x] there are 2 fieldset elements plus their associated legend elements that are not grouping form inputs — they are not being used semantically. One wrapping the table and one for “Recent Additions”.
[x] all tables need a caption element, as the first child, that describes the structure of the table for those who cannot see it: “The first column is the census year. The other columns give the number of Pieces online, the total number of Pieces for the year, the percentage of these that are online and the number of Pieces added in the last 30 days.”
[x] the first table column holds row headings: mark up as th scope=“row”
[x] the final table row can be wrapped in a tfooter element. The first cell is a th scope=“row” and “Totals” works better than “Total” - not sure I agree with using Totals rather than Total but Ive changed it anyway
[x] the text above the table mentions “The National Archives” — this is for England and Wales only. There is no mention of the “National Records of Scotland”
once the legends are gone, review the headings
Other issues: the opening page is not fully responsive — the columns start to overlap on screens that are a bit wider then palm. Review once the non-semantic fieldsets are gone. - Seems ok to me now. surely it is the presence of years (rather than brackets) in the Place select that is important? S-R users will not know that the brackets are there - re-worded using brackets with meaning will be lost on S-R users who will not know they are there. (In some displays the space is missing between the Civil Parish name and the list of hamlets, etc.) - this is a feature of the way this data is held in the database “You may view the Database Records for …” is ambiguous, even misleading - re-worded there is no need to put the top heading in a grid grid__item, unless the grid is inherited from a partial? - Addressed I hope(?)
@AnneV-Learn First, apologies for some misleading descriptions of the issues — I've amended those. The description of how to use the scope
attribute is entirely my fault. I've only just become aware that the initial description of how to use the caption
element is flawed — unfortunately, there is a lot of misinformation out there, but actually using a screen reader is very revealing.
I'm going to look at your changes, make some notes, and then we can tackle the next round of improvements. So far so good. Thank you!
Updates made and deployed to Test3 for second round of assessment by @AlOneill
@AnneV-Learn has made accessibility improvements to the main Records page (all counties) and the page for a single county.
We will be moving on next to fix a few additional things on the page for a single Place. After that, we will tackle the displays that list Pieces and Names.
@AnneV-Learn to contact Alison about restarting (and redeploy code to test 3)
@AnneV-Learn to review Names letter selection in terms on in-page navigation rather than a new page load
I am not totally convinced that switching to in-page navigation for presenting the unique names filtered by initial letter is the way to go:
if we switch to in-page navigation the user will potentially have to scroll an awfully long way up to the top of the page to take the next 'action’. Many of the lists of unique names are very long - just one example: Somerset Bedminster 1861 has 2772 unique surnames.
in my opinion the time to bring back the filtered results page as it stands is really not at all slow.
with our most recent server upgrades I believe that response time is really not an issue for this sort of straightforward db lookup (the unique names for places are held in a separate db table (collection) which is refreshed nightly).
Interesting. Time was never my main concern here.
we can offer the user in-page navigation to return to the top of the page (and many will also be able to use cmd + up-arrow, or the equivalent for their OS)
in-page navigation avoids the use of the extra electricity required to format the listing again — and we will need to format each part (letter grouping) as a proper list in order to make the names accessible for a screen-reader user — more on that later …
we are fortunate to have good internet access in the UK — not all corners of the world have the same ease of access and pretty much unlimited data allowances
Ok @AlOneill - I have made changes to the Names page (in-page navigation, the names are now in 'lists' and there are 'Back to top of page' links). This may still not be completely what you want but hopefully it is on the right track. It has been deployed to Test3 (along with re-instating the changes that were already made to address accessibility issues).
@AnneV-Learn I've had a quick look at a Surnames page and it is three steps in the right direction. Well done.
I was a little disappointed to see an isolated <li class="grid">
:-( especially as it visibly throws the whole page out of kilter. And BTW, there is no such element as an <nl>
!!
It will take me a few days at least to work through the page (my personal batteries are very depleted) and make some sensible suggestions for improvement — I do not want to give you suggestions with duff side-effects and there is a lot to pull together on a page such as this.
Updates to Place Names page provided by Alison implemented on Test3
@AlOneill to test
The Records page looks very good — very neat — but it has a number of issues related to display and accessibility.
Many of the issues on this page are inter-related, that is they need to solved together and the nature of the fix will determine the details. So, where to start? Fixing the table issues could be a good place.
[x] there are 2
fieldset
elements plus their associatedlegend
elements that are not grouping form inputs — they are not being used semantically. One wrapping the table and one for "Recent Additions".[ ] all tables need a brief
caption
element, as the first child, that describes the structure of the table for those who cannot see it.[x] the first table column of the
tbody
rows holds row headings: mark up asth scope="row"
while thethead
cells should be marked up withth scope="col"
[x] the final table row can be wrapped in a
tfooter
element. The first cell is ath scope="row"
and "Totals" works better than "Total"[x] the text above the table mentions "The National Archives" — this is for England and Wales only. There is no mention of the "National Records of Scotland"
[ ] once the legends are gone, review the headings
Other issues:
[ ] the opening page is not fully responsive — the columns start to overlap on screens that are a bit wider then palm. Review once the non-semantic fieldsets are gone.
[x] surely it is the presence of years (rather than brackets) in the Place select that is important? S-R users will not know that the brackets are there
[ ] using brackets with meaning will be lost on S-R users who will not know they are there. (In some displays the space is missing between the Civil Parish name and the list of hamlets, etc.)
[ ] "You may view the Database Records for …" is ambiguous, even misleading
[ ] there is no need to put the top heading in a
grid grid__item
, unless thegrid
is inherited from a partial?Issues that need policy decisions:
[ ] There is no
h1
element in the CEN header and so noh1
element on the page; links that are styled to look like buttons are potentially confusing for a keyboard-only user because they behave differently[ ] blocks of centred text look neat but are more difficult to read — impossible for some