coreui / coreui-pro / 36894057553

96%

main: 94%

push

github

feat(Calendar): name each week number for screen readers (#1512)

* feat(Calendar): name each week number for screen readers

The week numbers were row headers named by the number alone, so a screen
reader moving between rows said 36 with nothing to say what it counts. Each
week number now carries aria-label with the locale's word for week and the
number (Week 36, Tydzień 36), and the new ariaWeekNumberLabel option takes a
function of the week number to name it yourself. The date pickers pass it on
to their calendar.

* fix(Calendar): put the week number in a week row's name and mark it a row header

In week selection the focused row is named by the days it spans, so its week
number was never announced; with week numbers shown, the row's name now
starts with the week number's name (Week 36, August 31 – September 6, 2026).
The week-number cell gets scope="row", so a row of empty cells does not turn
it into a column header, and getWeekNumberName in the utils builds the name
once for every edition, keeping the default when the label function returns
nothing. Measured in Chromium's accessibility tree: the cell is a rowheader
named Week 36 (Tydzień 36 in pl-PL). The docs say the option is set in
JavaScript and how to name week numbers in a locale that writes the number
first.

* chore: raise the JS bundle budgets for the week-number names

Measured against v6-dev with gzip -9 on the built bundles: coreui.bundle.js
+243 B, coreui.esm.js +252 B, coreui.js +244 B, the minified bundles +63 to
+67 B. coreui.js went over its ceiling and the others were left with 20 to
130 B, so each ceiling now keeps at least 0.25 kB of room.

* fix(Calendar): ask for week number names only while they are shown

The calendar called ariaWeekNumberLabel for every row even with week numbers
hidden; it now builds the name only when showWeekNumber is on. The label's
type allows returning undefined, which keeps the default name, as the docs
say. Specs cover a custom name in a week row... (continued)

6669 of 7217 branches covered (92.41%)

Branch coverage included in aggregate %.

9 of 9 new or added lines in 2 files covered. (100.0%)

11789 of 12083 relevant lines covered (97.57%)

1389.08 hits per line