WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: SCOPE

for

From: Sailesh Panchang
Date: Oct 23, 2024 7:12AM

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 REMOVED>
Deque Systems Inc | - Accessibility for Good | www.deque.com














On Tue, Oct 22, 2024 at 2:46 PM Birkir R. Gunnarsson <
<EMAIL 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 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 REMOVED>
> > Deque Systems Inc | - Accessibility for Good | www.deque.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Oct 22, 2024 at 5:56 AM Birkir R. Gunnarsson <
> > <EMAIL 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.
> > > > >