Issues on attendance tracking feature

[radinamatic]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Target branch: release-0.19.x
Tested the asset from #14382 on Windows 10, Ubuntu 22, and a tablet with Android 13.

Observed behavior

1. When first I noticed that the arrow buttons for pagination on Mark attendance and Edit attendance pages were not keyboard navigable, it looked like it was only because of low number of learners, but even when I enrolled more (from 16 to 46), the list was still not paginated. Not sure where the threshold is for the number of learners in the class to be moved to the second page, but maybe it should be 10, same as on Attendance History page where arrow buttons are focusable.

   Mark attendance	Edit attendance

2. Other accessibility issues include the 🔍 icon in the search field which is a span with no role, but with aria-label (throws a validation error), and insufficient contrast for absent learners in the count summary at the bottom of Mark attendance and Edit attendance pages.

   

   Since 🔍 is purely decorative icon, and the search field has its own aria-label, let's just remove the aria-label from the icon's span.

3. In Chrome on both Windows and Ubuntu there are some weird and unnecessary horizontal scrollbars in all the cells with toggles in Mark attendance and Edit attendance pages, plus a vertical one in the bottom bar. Firefox on Windows displays only the latter, while Firefox on Ubuntu displays none (winner! 😂)

   Firefox	Chrome

4. (low priority) Buttons in the modal are too close and focus outline overlaps.

   1	2

[marcellamaki]

the list was still not paginated

the pagination threshold for marking attendance is 50 learners, because we anticipate groups of 35-45 learners per VE mentor/coach, and wanted to be sure they could mark all of the learners on a single screen via scroll without having to navigate back and forth across pages. if we get feedback from them that more pagination is better, we can change it. for now, let's not worry about it.

the search field which is a span with no role

does

<form role="search">
  <input type="search">
</form>

make more sense, @radinamatic ?

insufficient contrast for absent learners

let's just use the same text color for both for now

some weird and unnecessary horizontal scrollbars in all the cells with toggles in Mark attendance and Edit attendance pages, plus a vertical one in the bottom bar

i do not know what is going on here but let's definitely fix it 😅

Buttons in the modal are too close and focus outline overlaps

yes, this is a P1 but hopefully a very quick fix

[radinamatic]

<form role="search">
  <!-- search input -->
</form>

is definitely an option, but wouldn't it be easier to just remove the aria-label from the span where the icon is? Screen reader output it Ok, it's just triggering validation errors, as non-semantic element as span without a proper role is not allowed aria-label

Since search input field is properly announced by the screen reader as it has its own aria-label , adding the aria-label to the 🔍 icon that precedes it is superfluous, imho

[marcellamaki]

wouldn't it be easier to just remove the aria-label from the span where the icon is?

ah, yes, i misunderstood the issues there -- that sounds better to me

[akolson]

@marcellamaki @radinamatic, just noting here that we don't have a span, if anything its managed by KeenUI's UiIcon so we will be removing the aria-label setting for this. Also worth noting that this change affects other parts of the code base that use the PaginatedListContainer component via the FilterTextbox component

[marcellamaki]

so, does this for example have the same underlying implementation as the facility users filtering, @akolson ?

[marcellamaki]

I think if it's the same implementation as in other places (and we're just noticing the a11y considerations), let's not make a wider fix right now @akolson, and target that to our next release. i can coordinate with @radinamatic on that piece

[akolson]

so, does this for example have the same underlying implementation as the facility users filtering, @akolson ?

Accessibility wise --yes, for any table that uses the PaginatedListContainer. I however don't think the above is using the search field block (within PaginatedListContainer) that this change affects. The only component using the search field block in the PaginatedListContainer is the IndividualLearnerSelector although it seems quite used, so it's probably best to hold off any changes for now!