tech/html/headers-attribute
stevefaulkner opened this issue · 4 comments
The requirement in the test is that moving virtual focus to the cell will result in JAWS announcing the headers for the cell. What is this requirement based on?
In JAWS 2023/Chrome Version 107.0.5304.107 (Official Build) (64-bit) when a cell has virtual focus, pressing Ctrl+Alt+(numpad) 5 results in the correct headers being announced. This is a different method to what is required, but it does result in the desired information.
I am wondering what the basis of the MUST level requirement when it is not defined in a specification?
To hear information about the current table cell, press ALT+CTRL+NUM PAD 5. JAWS announces the row and column position, reads the current row and column headers, and reads the contents of the cell.
source: JAWS help file
Hi Steve, thank you for this.
I think there might be a misunderstanding here. A11ysupport.io just lists the expectation as screen readers must “convey the defined cell headers”. Screen readers and other AT certainly have freedom in how they choose to convey the information, and I don’t mean to imply the table navigation commands are the only way that a screen reader can meet the expectation.
The “MUST” language for the expectation is derived from the existence of the attribute and the intended functionality that is hinted at by standards (HTML in this case). Because there isn’t a standard for how screen readers need to behave (and a11ysupport.io isn’t such a standard), this project instead tries to make educated guesses - and that can get messy.
Any feedback or suggestions are welcome for how to improve this. Ultimately I’d like to see this project replaced by aria-at which has a better model for this (but also has a much smaller scope). I’ll think on some ways to make it clearer myself.
That being said, the typical behavior for Jaws is to announce new headers when navigating by table commands. This appears to hold true for both typical <th> based headers and even the headers attribute in some scenarios (see the multi-level example). I had assumed that the same behavior was expected here, which is apparently an incorrect assumption (sorry about that). But it does make me wonder… why does the behavior differ with this scenario, why shouldn’t users expect to hear the header when navigating to the cell with table commands? I only ask for my own understanding and so that I can document it to help others understand.
I’ll get these test results updated such that they pass.
I have updated support for the headers attribute and JAWS/chrome and JAWS/edge are now listed as having support. https://a11ysupport.io/tech/html/headers_attribute
Also, I added this note to all pages (feedback and suggestions are still welcome).
Important: This website does not attempt to establish a standard for how assistive technologies (such as screen readers) must behave or dictate how assistive technologies must provide support (no such standard exists). It should not be used as the only source for determining if something is supported. Instead, it is meant to help visitors get a head start in understanding behaviors, general expectations, and support.
I'm going to close this for now. Please open another issue if further discussion is needed.