E-mail List Archives
Thread: SCOPE
Number of posts in this thread: 9 (In chronological order)
From: Glarst
Date: Mon, Oct 21 2024 8:32AM
Subject: SCOPE
No previous message | Next message →
I've been asked to provide a real-world example of a barrier caused by the
absence of SCOPE on an otherwise conformant TH tag. This pertains
specifically to the recent Title II Final Rule, so I guess the bigger
question is whether SCOPE is required for conformance.
So before I go on a wild goose chase evaluating every table on the WWW,
does anyone have a hot take on this (or a real-world instance they'd like
to share)?
Thanks,
Glarst
From: Hayman, Douglass
Date: Mon, Oct 21 2024 8:56AM
Subject: Re: - SCOPE
← Previous message | Next message →
I'd say, make two tables, one with scope, one without for both a web page and something like a PDF file and then navigate through the table with NVDA or JAWS to see the real world experience.
Doug Hayman
IT Accessibility Coordinator
Information Technology
Olympic College
= EMAIL ADDRESS REMOVED =
(360) 475-7632
From: Laura Roberts
Date: Mon, Oct 21 2024 9:25AM
Subject: Re: SCOPE
← Previous message | Next message →
Use a screen reader on a table with a ton of data cells.
Talk about how if we lose our place, we can see where we are at a glance by
looking at where the row header and column header and data cell intersect.
Ask how could you tell where you are in this table without being able to
see? (Answer is you have to listen to the whole damn thing again)
Then use the screen reader say cell contents command on a table with and
without scope set. (CTRL ALT Numpad 5 in Jaws). Becomes crystal clear why
it's needed.
On Mon, Oct 21, 2024, 10:33 AM Glarst < = EMAIL ADDRESS REMOVED = > wrote:
> I've been asked to provide a real-world example of a barrier caused by the
> absence of SCOPE on an otherwise conformant TH tag. This pertains
> specifically to the recent Title II Final Rule, so I guess the bigger
> question is whether SCOPE is required for conformance.
> So before I go on a wild goose chase evaluating every table on the WWW,
> does anyone have a hot take on this (or a real-world instance they'd like
> to share)?
> Thanks,
> Glarst
> > > > >
From: Jared Smith
Date: Mon, Oct 21 2024 9:31AM
Subject: Re: SCOPE
← Previous message | Next message →
At WebAIM we recently conducted testing on a wide variety of tables to answer this precise question. For basic tables most browser and screen readers properly assume the correct header scope. However, in cases where the top left cell is a row header, where a table has only row headers (no column headers), or when spanned header cells are present, implementation of the scope attribute provides a much more accessible experience in several cases. A more notable finding is that table accessibility support is still quite poor, even when scope is properly implemented.
The test cases are at https://webaim.org/temp/tabletest.htm
The test results for VoiceOver, VoiceOver Mobile, and NVDA are at
https://docs.google.com/spreadsheets/d/1QNjleey20PzIB9s814uPQHQFzq9c25UkPJl7K_rzvVQ/edit?usp=sharing The highlighted cells are those in which scope is properly implemented, but the support is not good.
In short, we still recommend the scope attribute because it has positive accessibility benefits, though in some cases tables are accessible regardless, and in some other cases the tables are inaccessible regardless.
Jared Smith
From: Dax Castro
Date: Mon, Oct 21 2024 9:32AM
Subject: Re: SCOPE
← Previous message | Next message →
Any table that has row headers would provide a poor user experience. When a person is moving from row to row. Because without the scope of row for the items in the first column, the information would not be voiced correctly. This is a clear violation of 1.3.1 info and relationships.
Also, any table that has more than one column header would not voice correctly without scope as well. By default, NVDA and JAWS only assume that the first row contain column headers. Therefore, any table that exceeds this simple design will fail for the end user to provide an accurate experience.
Thanks,
Dax
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Laura Roberts < = EMAIL ADDRESS REMOVED = >
Sent: Monday, October 21, 2024 8:25:30 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] SCOPE
Use a screen reader on a table with a ton of data cells. Talk about how if we lose our place, we can see where we are at a glance by looking at where the row header and column header and data cell intersect. Ask how could you tell where you
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Laura Roberts < = EMAIL ADDRESS REMOVED = >)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fa267a40fcb1fe78fbd93fd9e086ec2c19d07abdab8582f893f957c13d885eda65d43ddc55150f3ed38a607994f564ac0110a6f88aab7269d183f3017cf20eb352626fd8d5ca1a82527d1b0b36cb234f5c046e28aee0c26d85b717eb7fe5727cb23a764d2fe164a5c7aabff48c42b2adf25cbba52d15f50fad7318bb9a37ea96d6e5ba769f456f9eee83a10803e981ceb114c06941dd1e69648de6664abf83231c4817aa562dfd8aa880254c8054f37c03568900c7b1f650dfe116508bf13dc37608ffa311c22782eae12ce844c5337d199d905f7d4bbbc67>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fa267a40fcb1fe78fbd93fd9e086ec2c19d07abdab8582f893f957c13d885eda65d43ddc55150f3ed38a607994f564ac0110a6f88aab7269d183f3017cf20eb352626fd8d5ca1a82527d1b0b36cb234f5c046e28aee0c26d85b717eb7fe5727cb23a764d2fe164a5c7aabff48c42b2adf25cbba52d15f50fad7318bb9a37ea96d6e5ba769f456f9eee83a10803e981ceb114c06941dd1e69648de6664abf83231c4817aa562dfd8aa880254c8054f37c03568900c7b1f650dfe116508bf13dc37608ffa311c22782eae12ce844c5337d199d905f7d4bbbc67>
Potential Impersonation
The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message.
NkdkJdXPPEBannerEnd
Use a screen reader on a table with a ton of data cells.
Talk about how if we lose our place, we can see where we are at a glance by
looking at where the row header and column header and data cell intersect.
Ask how could you tell where you are in this table without being able to
see? (Answer is you have to listen to the whole damn thing again)
Then use the screen reader say cell contents command on a table with and
without scope set. (CTRL ALT Numpad 5 in Jaws). Becomes crystal clear why
it's needed.
On Mon, Oct 21, 2024, 10:33 AM Glarst < = EMAIL ADDRESS REMOVED = > wrote:
> I've been asked to provide a real-world example of a barrier caused by the
> absence of SCOPE on an otherwise conformant TH tag. This pertains
> specifically to the recent Title II Final Rule, so I guess the bigger
> question is whether SCOPE is required for conformance.
> So before I go on a wild goose chase evaluating every table on the WWW,
> does anyone have a hot take on this (or a real-world instance they'd like
> to share)?
> Thanks,
> Glarst
> > > > >
From: Birkir R. Gunnarsson
Date: Tue, Oct 22 2024 3:55AM
Subject: Re: SCOPE
← Previous message | Next message →
Any <th> cell in the first row in a table has an implicit scope of "col".
(i.e. column header)
Any <th> cell in the first column in a table (not counting the first row)
has an implicit scope of "row".
Adding a scope attribute to those cells typically does not change
accessibility support, in my experience.
(I have not yet looked at the latest experiments from the mighty WebAIM
team)
You do need a scope attribute for
* Any <th> cell that is not in the first row or first column in the table,
(scope="col" for a column header, scope="row" for a row header)
* Any <th> cell that spans multiple columns or rows,
* use the scope attribute with values of colgroup or rowgroup respectively
and use the colspan or rowspan attributes to indicate number of columns or
rows spanned
* <th scope="colgroup" colspan="3">I am a column header cell spanning 3
columns</th>
* <th scope="rowgroup" rowspan="3">I am a header cell spanning 3 rows</th>
You need to do this regardless of the location of the <th> cell in the
table.
I disagree that a table with only column or row headers fails WCAG 1.3.1,
it all depends on
I) Whether a cell is visually emphasized
II) If the table has a natural candidate
A table needs either column or row header cells, usually it needs column
header cells, but it does not necessarily need both.
Since screen readers read header cells in context, you don't want those
cells to be too wordy.
Imagine that you have a table of transactions. The first column is a
30-digit transaction ID, Then you have the columns date, amount, from
account and to account.
The transaction number doesn't tell you anything, and you don't want to be
forced to hear it every time you navigate between rows, so it's a terrible
candidate for a row header.
Any one or more of the amount, date, or from account columns would be
acceptable row header candidates, though they don't tell the whole story,
probably date and amount would work together as row headers
I would personally prefer not having a row header in that table.
Actually what I do want is for screen reader users to set their own row
header cells, but that would be a screen reader functionality.
From: Sailesh Panchang
Date: Tue, Oct 22 2024 11:15AM
Subject: Re: SCOPE
← Previous message | Next message →
Here is an example of a complex data table with multiple rows of column
headers (including use of colspan) that uses only TH and works fine to
expose the column headers.
Yet the row headers use the scope attribute with the TH in order to
explicitly define the row header relationship. Notice the table uses
rowspan so again in effect there are multiple columns of row headers
thatneed to be related with the data cells.
http://mars.dequecloud.com/demo/Table-multi-colWithRowspan.htm
This was authored over ten years ago and the behavior is the same even with
an HTML5 doctype statement.
So the scope attribute needs to be used in order to expose the header cell
- data cell relationship unambiguously in such complex data tables.
Financial or statistical tables can often have non-simple structures.
So my recommendation is:
- use only TH;
- If that is not sufficient, check if adding scope helps to expose the
relationships as intended;
- And if this still does not work, using headers-id method may be the only
option.
Thanks,
Sailesh Panchang | +1 (571) 344-1765
Technical Solutions Architect
Email: = EMAIL ADDRESS REMOVED =
Deque Systems Inc | - Accessibility for Good | www.deque.com
On Tue, Oct 22, 2024 at 5:56 AM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> Any <th> cell in the first row in a table has an implicit scope of "col".
> (i.e. column header)
> Any <th> cell in the first column in a table (not counting the first row)
> has an implicit scope of "row".
> Adding a scope attribute to those cells typically does not change
> accessibility support, in my experience.
> (I have not yet looked at the latest experiments from the mighty WebAIM
> team)
>
>
> You do need a scope attribute for
> * Any <th> cell that is not in the first row or first column in the table,
> (scope="col" for a column header, scope="row" for a row header)
> * Any <th> cell that spans multiple columns or rows,
> * use the scope attribute with values of colgroup or rowgroup respectively
> and use the colspan or rowspan attributes to indicate number of columns or
> rows spanned
> * <th scope="colgroup" colspan="3">I am a column header cell spanning 3
> columns</th>
> * <th scope="rowgroup" rowspan="3">I am a header cell spanning 3 rows</th>
> You need to do this regardless of the location of the <th> cell in the
> table.
>
> I disagree that a table with only column or row headers fails WCAG 1.3.1,
> it all depends on
> I) Whether a cell is visually emphasized
> II) If the table has a natural candidate
>
> A table needs either column or row header cells, usually it needs column
> header cells, but it does not necessarily need both.
>
> Since screen readers read header cells in context, you don't want those
> cells to be too wordy.
>
> Imagine that you have a table of transactions. The first column is a
> 30-digit transaction ID, Then you have the columns date, amount, from
> account and to account.
> The transaction number doesn't tell you anything, and you don't want to be
> forced to hear it every time you navigate between rows, so it's a terrible
> candidate for a row header.
> Any one or more of the amount, date, or from account columns would be
> acceptable row header candidates, though they don't tell the whole story,
> probably date and amount would work together as row headers
>
> I would personally prefer not having a row header in that table.
>
> Actually what I do want is for screen reader users to set their own row
> header cells, but that would be a screen reader functionality.
> > > > >
From: Birkir R. Gunnarsson
Date: Tue, Oct 22 2024 12:46PM
Subject: Re: SCOPE
← Previous message | Next message →
.. and ideally, split the complex table up into multiple simpler tables.
Trust me, as someone who has been working on financial services tables for
almost 10 years now I can't count the time I wish people had opted to
build multiple simple tables instead of one complex monster table.
Admittedly it doesn't happen all tat often, but at least we can ask. ;)
On Tue, Oct 22, 2024 at 1:15 PM Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
wrote:
> Here is an example of a complex data table with multiple rows of column
> headers (including use of colspan) that uses only TH and works fine to
> expose the column headers.
> Yet the row headers use the scope attribute with the TH in order to
> explicitly define the row header relationship. Notice the table uses
> rowspan so again in effect there are multiple columns of row headers
> thatneed to be related with the data cells.
> http://mars.dequecloud.com/demo/Table-multi-colWithRowspan.htm
>
> This was authored over ten years ago and the behavior is the same even with
> an HTML5 doctype statement.
> So the scope attribute needs to be used in order to expose the header cell
> - data cell relationship unambiguously in such complex data tables.
> Financial or statistical tables can often have non-simple structures.
> So my recommendation is:
> - use only TH;
> - If that is not sufficient, check if adding scope helps to expose the
> relationships as intended;
> - And if this still does not work, using headers-id method may be the only
> option.
> Thanks,
> Sailesh Panchang | +1 (571) 344-1765
> Technical Solutions Architect
>
> Email: = EMAIL ADDRESS REMOVED =
> Deque Systems Inc | - Accessibility for Good | www.deque.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 22, 2024 at 5:56 AM Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Any <th> cell in the first row in a table has an implicit scope of "col".
> > (i.e. column header)
> > Any <th> cell in the first column in a table (not counting the first row)
> > has an implicit scope of "row".
> > Adding a scope attribute to those cells typically does not change
> > accessibility support, in my experience.
> > (I have not yet looked at the latest experiments from the mighty WebAIM
> > team)
> >
> >
> > You do need a scope attribute for
> > * Any <th> cell that is not in the first row or first column in the
> table,
> > (scope="col" for a column header, scope="row" for a row header)
> > * Any <th> cell that spans multiple columns or rows,
> > * use the scope attribute with values of colgroup or rowgroup
> respectively
> > and use the colspan or rowspan attributes to indicate number of columns
> or
> > rows spanned
> > * <th scope="colgroup" colspan="3">I am a column header cell spanning 3
> > columns</th>
> > * <th scope="rowgroup" rowspan="3">I am a header cell spanning 3
> rows</th>
> > You need to do this regardless of the location of the <th> cell in the
> > table.
> >
> > I disagree that a table with only column or row headers fails WCAG 1.3.1,
> > it all depends on
> > I) Whether a cell is visually emphasized
> > II) If the table has a natural candidate
> >
> > A table needs either column or row header cells, usually it needs column
> > header cells, but it does not necessarily need both.
> >
> > Since screen readers read header cells in context, you don't want those
> > cells to be too wordy.
> >
> > Imagine that you have a table of transactions. The first column is a
> > 30-digit transaction ID, Then you have the columns date, amount, from
> > account and to account.
> > The transaction number doesn't tell you anything, and you don't want to
> be
> > forced to hear it every time you navigate between rows, so it's a
> terrible
> > candidate for a row header.
> > Any one or more of the amount, date, or from account columns would be
> > acceptable row header candidates, though they don't tell the whole story,
> > probably date and amount would work together as row headers
> >
> > I would personally prefer not having a row header in that table.
> >
> > Actually what I do want is for screen reader users to set their own row
> > header cells, but that would be a screen reader functionality.
> > > > > > > > > >
> > > > >
--
Work hard. Have fun. Make history.
From: Sailesh Panchang
Date: Wed, Oct 23 2024 7:12AM
Subject: Re: SCOPE
← Previous message | No next message
Hello Birkir,
Data tables present information and importantly, functionality too.
Sometimes these formats are mandated or have been accepted as the standard
practice.
Columns and row groups allow for comparison of data - something that is
difficult to do across multiple tables without relying on memory and extra
navigation.
When HTML / ARIA markup allow for complex tables to be marked up so that
users can get to the same information as everyone else, I do not see a
problem.
As I noted in the last email, it is always better to use the scope
attribute and the headerrs-id method only when needed to make the
header-data cell relationship unambiguous for browsers and assistive
technologies. There is no alternative to testing the table markup to make
sure it meets accessibility requirements.
Breaking up tables into simpler ones might work in some situations but one
needs to make sure functionality and ease of getting to information are not
sacrificed.
Here is another example I had worked on many years ago:
http://mars.dequecloud.com/demo/Census_2013.htm
Note: the second table uses h3 within the table which might fail validation
but yet works with JAWS and NVDA.
Thanks,
Sailesh Panchang | +1 (571) 344-1765
Technical Solutions Architect
Email: = EMAIL ADDRESS REMOVED =
Deque Systems Inc | - Accessibility for Good | www.deque.com
On Tue, Oct 22, 2024 at 2:46 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> .. and ideally, split the complex table up into multiple simpler tables.
> Trust me, as someone who has been working on financial services tables for
> almost 10 years now I can't count the time I wish people had opted to
> build multiple simple tables instead of one complex monster table.
> Admittedly it doesn't happen all tat often, but at least we can ask. ;)
>
>
> On Tue, Oct 22, 2024 at 1:15 PM Sailesh Panchang <
> = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Here is an example of a complex data table with multiple rows of column
> > headers (including use of colspan) that uses only TH and works fine to
> > expose the column headers.
> > Yet the row headers use the scope attribute with the TH in order to
> > explicitly define the row header relationship. Notice the table uses
> > rowspan so again in effect there are multiple columns of row headers
> > thatneed to be related with the data cells.
> > http://mars.dequecloud.com/demo/Table-multi-colWithRowspan.htm
> >
> > This was authored over ten years ago and the behavior is the same even
> with
> > an HTML5 doctype statement.
> > So the scope attribute needs to be used in order to expose the header
> cell
> > - data cell relationship unambiguously in such complex data tables.
> > Financial or statistical tables can often have non-simple structures.
> > So my recommendation is:
> > - use only TH;
> > - If that is not sufficient, check if adding scope helps to expose the
> > relationships as intended;
> > - And if this still does not work, using headers-id method may be the
> only
> > option.
> > Thanks,
> > Sailesh Panchang | +1 (571) 344-1765
> > Technical Solutions Architect
> >
> > Email: = EMAIL ADDRESS REMOVED =
> > Deque Systems Inc | - Accessibility for Good | www.deque.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Oct 22, 2024 at 5:56 AM Birkir R. Gunnarsson <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > Any <th> cell in the first row in a table has an implicit scope of
> "col".
> > > (i.e. column header)
> > > Any <th> cell in the first column in a table (not counting the first
> row)
> > > has an implicit scope of "row".
> > > Adding a scope attribute to those cells typically does not change
> > > accessibility support, in my experience.
> > > (I have not yet looked at the latest experiments from the mighty WebAIM
> > > team)
> > >
> > >
> > > You do need a scope attribute for
> > > * Any <th> cell that is not in the first row or first column in the
> > table,
> > > (scope="col" for a column header, scope="row" for a row header)
> > > * Any <th> cell that spans multiple columns or rows,
> > > * use the scope attribute with values of colgroup or rowgroup
> > respectively
> > > and use the colspan or rowspan attributes to indicate number of columns
> > or
> > > rows spanned
> > > * <th scope="colgroup" colspan="3">I am a column header cell spanning
> 3
> > > columns</th>
> > > * <th scope="rowgroup" rowspan="3">I am a header cell spanning 3
> > rows</th>
> > > You need to do this regardless of the location of the <th> cell in the
> > > table.
> > >
> > > I disagree that a table with only column or row headers fails WCAG
> 1.3.1,
> > > it all depends on
> > > I) Whether a cell is visually emphasized
> > > II) If the table has a natural candidate
> > >
> > > A table needs either column or row header cells, usually it needs
> column
> > > header cells, but it does not necessarily need both.
> > >
> > > Since screen readers read header cells in context, you don't want those
> > > cells to be too wordy.
> > >
> > > Imagine that you have a table of transactions. The first column is a
> > > 30-digit transaction ID, Then you have the columns date, amount, from
> > > account and to account.
> > > The transaction number doesn't tell you anything, and you don't want to
> > be
> > > forced to hear it every time you navigate between rows, so it's a
> > terrible
> > > candidate for a row header.
> > > Any one or more of the amount, date, or from account columns would be
> > > acceptable row header candidates, though they don't tell the whole
> story,
> > > probably date and amount would work together as row headers
> > >
> > > I would personally prefer not having a row header in that table.
> > >
> > > Actually what I do want is for screen reader users to set their own row
> > > header cells, but that would be a screen reader functionality.
> > > > > > > > > > > > > > >
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >