E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Alan Zaitchik
Date: Fri, Sep 13 2019 2:06PM
Subject: Turning in/off inaccessible feature
No previous message | Next message →

I was asked about a complicated grid that becomes inaccessible when the leftmost column is "pinned" to the margin. This pinning is very important for sighted users due to the number of columns in the grid and the horizontal scrolling that is needed. But for reasons that i cannot go into here, pinning the column prevents the cells in that column from functioning as row headers. The grid is very large and needs row headers to be comprehensible— for the very same reason sighted users need to pin the leftmost column!
If we place a button on the page that controls the pinning (and thus the accessibility) does anyone have a problem with that? It seems to me that under the circumstances the burden is a single button click for someone, either to turn on or turn off the pinning — probably, given the numbers, to turn it off— but no more than that. Yet some on our team feel this might be considered unequal access.
Any thoughts?
A

From: Jonathan Cohn
Date: Fri, Sep 13 2019 2:14PM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

This is essentially the solution I went with last year for a similar issue. My feeling as long as the data is being generated from the same source, this is not a separate and unequal issue. You are actually improving the feedback for all users in this case. Determining the wording of that pin was a bit of a negotiation, and i don't remember the final result.
Jonathan Cohn


> On Sep 13, 2019, at 4:06 PM, Alan Zaitchik < = EMAIL ADDRESS REMOVED = > wrote:
>
> I was asked about a complicated grid that becomes inaccessible when the leftmost column is "pinned" to the margin. This pinning is very important for sighted users due to the number of columns in the grid and the horizontal scrolling that is needed. But for reasons that i cannot go into here, pinning the column prevents the cells in that column from functioning as row headers. The grid is very large and needs row headers to be comprehensible— for the very same reason sighted users need to pin the leftmost column!
> If we place a button on the page that controls the pinning (and thus the accessibility) does anyone have a problem with that? It seems to me that under the circumstances the burden is a single button click for someone, either to turn on or turn off the pinning — probably, given the numbers, to turn it off— but no more than that. Yet some on our team feel this might be considered unequal access.
> Any thoughts?
> A
> > > >

From: glen walker
Date: Fri, Sep 13 2019 3:36PM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

I'm guessing the pinning of the column effectively takes that column out of
the table so that you can scroll the rest of it. I tried playing with a
simple example to visually hide the table column but leave it in the table
but my 5 min attempts didn't work. But I think the idea is worth
pursuing. I also tried the headers attribute on the <td> but didn't have
much luck with that either. But as mentioned, it was a quick test and only
tried NVDA on firefox.

From: Lucy GRECO
Date: Fri, Sep 13 2019 3:50PM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

Having the ability to turn off the column might be useful for more people
than just screen reader users however it really goes against my instinct to
come up with an alternative format just for screen reader users

On Fri, Sep 13, 2019, 2:36 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> I'm guessing the pinning of the column effectively takes that column out of
> the table so that you can scroll the rest of it. I tried playing with a
> simple example to visually hide the table column but leave it in the table
> but my 5 min attempts didn't work. But I think the idea is worth
> pursuing. I also tried the headers attribute on the <td> but didn't have
> much luck with that either. But as mentioned, it was a quick test and only
> tried NVDA on firefox.
> > > > >

From: Jonathan Cohn
Date: Sun, Sep 15 2019 8:47AM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

I would agree, but we found no good way of doing this with HTML and CSS without a miserable hack of actually having two or three tables and using CSS z index to slide the true data under the table headers. When the button to turn on accessibility is checked, the entire thing is replaced with a single table that follows accessibility best practices.
If CSS / HTML tables had a way to mark certain columns as floating when scrolling, or if clients would allow only tables that fit on screen, then this mess could be avoided.

Best wishes,

Jonathan Cohn



> On Sep 13, 2019, at 5:50 PM, Lucy GRECO < = EMAIL ADDRESS REMOVED = > wrote:
>
> Having the ability to turn off the column might be useful for more people
> than just screen reader users however it really goes against my instinct to
> come up with an alternative format just for screen reader users
>
> On Fri, Sep 13, 2019, 2:36 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I'm guessing the pinning of the column effectively takes that column out of
>> the table so that you can scroll the rest of it. I tried playing with a
>> simple example to visually hide the table column but leave it in the table
>> but my 5 min attempts didn't work. But I think the idea is worth
>> pursuing. I also tried the headers attribute on the <td> but didn't have
>> much luck with that either. But as mentioned, it was a quick test and only
>> tried NVDA on firefox.
>> >> >> >> >>
> > > >

From: Birkir R. Gunnarsson
Date: Mon, Sep 16 2019 6:35AM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

You can hack the heck out of it with ARIA.
role="table"
role="row"
role="rowheader"
role="columnheader"
role="cell"

You can probably somehow fit these over your table in pinned mode, but
I think if there is a single button with clear wording about
functionality that you wouldn't have to.



On 9/15/19, Jonathan Cohn < = EMAIL ADDRESS REMOVED = > wrote:
> I would agree, but we found no good way of doing this with HTML and CSS
> without a miserable hack of actually having two or three tables and using
> CSS z index to slide the true data under the table headers. When the button
> to turn on accessibility is checked, the entire thing is replaced with a
> single table that follows accessibility best practices.
> If CSS / HTML tables had a way to mark certain columns as floating when
> scrolling, or if clients would allow only tables that fit on screen, then
> this mess could be avoided.
>
> Best wishes,
>
> Jonathan Cohn
>
>
>
>> On Sep 13, 2019, at 5:50 PM, Lucy GRECO < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Having the ability to turn off the column might be useful for more people
>> than just screen reader users however it really goes against my instinct
>> to
>> come up with an alternative format just for screen reader users
>>
>> On Fri, Sep 13, 2019, 2:36 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> I'm guessing the pinning of the column effectively takes that column out
>>> of
>>> the table so that you can scroll the rest of it. I tried playing with a
>>> simple example to visually hide the table column but leave it in the
>>> table
>>> but my 5 min attempts didn't work. But I think the idea is worth
>>> pursuing. I also tried the headers attribute on the <td> but didn't
>>> have
>>> much luck with that either. But as mentioned, it was a quick test and
>>> only
>>> tried NVDA on firefox.
>>> >>> >>> >>> >>>
>> >> >> >> >
> > > > >


--
Work hard. Have fun. Make history.

From: Sailesh Panchang
Date: Mon, Sep 16 2019 7:22AM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

What Birkir is referring to is something along the lines of what is
explained in this article in greater detail albeit for static column
headers:
Accessible Data Tables with Static Headers
http://juicystudio.com/article/accessible_data_tables_static_headers.php

Thanks,
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765


On 9/16/19, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> You can hack the heck out of it with ARIA.
> role="table"
> role="row"
> role="rowheader"
> role="columnheader"
> role="cell"
>
> You can probably somehow fit these over your table in pinned mode, but
> I think if there is a single button with clear wording about
> functionality that you wouldn't have to.
>
>
>
> On 9/15/19, Jonathan Cohn < = EMAIL ADDRESS REMOVED = > wrote:
>> I would agree, but we found no good way of doing this with HTML and CSS
>> without a miserable hack of actually having two or three tables and using
>> CSS z index to slide the true data under the table headers. When the
>> button
>> to turn on accessibility is checked, the entire thing is replaced with a
>> single table that follows accessibility best practices.
>> If CSS / HTML tables had a way to mark certain columns as floating when
>> scrolling, or if clients would allow only tables that fit on screen, then
>> this mess could be avoided.
>>
>> Best wishes,
>>
>> Jonathan Cohn
>>
>>
>>
>>> On Sep 13, 2019, at 5:50 PM, Lucy GRECO < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> Having the ability to turn off the column might be useful for more
>>> people
>>> than just screen reader users however it really goes against my instinct
>>> to
>>> come up with an alternative format just for screen reader users
>>>
>>> On Fri, Sep 13, 2019, 2:36 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>> I'm guessing the pinning of the column effectively takes that column
>>>> out
>>>> of
>>>> the table so that you can scroll the rest of it. I tried playing with
>>>> a
>>>> simple example to visually hide the table column but leave it in the
>>>> table
>>>> but my 5 min attempts didn't work. But I think the idea is worth
>>>> pursuing. I also tried the headers attribute on the <td> but didn't
>>>> have
>>>> much luck with that either. But as mentioned, it was a quick test and
>>>> only
>>>> tried NVDA on firefox.
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Todd Magnusson
Date: Mon, Sep 16 2019 4:47PM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

Hopefully I'm understanding the context accurately, throwing in my two cents in on the below comment "You can hack the heck out of it with ARIA", my advise would be to not reapply roles on elements with the role already. I've had interesting results with NVDA reading tables under those circumstances. I understand the reasoning of course (lets say you change the display model in CSS to let's say 'display: grid', but want to keep the table semantics.)

Also, I'd advise against floating headers, at least in mobile. iOS VoiceOver has huge focus management issues with fixed or absolute content in my own experience. Even in desktop, focus management for JAWS and NVDA has to be JavaScript assisted in certain scenarios.

- Todd

From: glen walker
Date: Mon, Sep 16 2019 5:06PM
Subject: Re: Turning in/off inaccessible feature
← Previous message | Next message →

The "hacking" comment and using the roles was not specifying roles on
elements that had the role already. When you specify role="presentation"
on a table, all rows and cells lose their identities. When you're hacking
two separate tables to appear as one table, you have to reapply the
appropriate roles to the <tr> and <td> elements.

On Mon, Sep 16, 2019 at 4:47 PM Todd Magnusson < = EMAIL ADDRESS REMOVED = > wrote:

> Hopefully I'm understanding the context accurately, throwing in my two
> cents in on the below comment "You can hack the heck out of it with ARIA",
> my advise would be to not reapply roles on elements with the role already.
> I've had interesting results with NVDA reading tables under those
> circumstances. I understand the reasoning of course (lets say you change
> the display model in CSS to let's say 'display: grid', but want to keep the
> table semantics.)
>
>
>

From: Mallory
Date: Tue, Sep 17 2019 2:41AM
Subject: Re: Turning in/off inaccessible feature
← Previous message | No next message

I've done the "sticky table header" thing in the past with 2 tables (one is aria-hidden so what sighted folks see (1 table) is what AT presents (1 table) however when those table columns are also interactive controls (sortable columns) that technique no longer works for every combination of user input.

However I recently was auditing a site where the client was doing several different types of sticky/scrolling tables and there was one they did which at least worked on desktop (I don't have any iThings so could not test mobile, although these were large dashboards which are simply nightmares on tiny mobile devices anyway).

The used a container around the table for scrolling, and used position: sticky or fixed on the thead (this was a case of the table headers being sticky rather than the first column). This seemed to work because the position attribute did not undo the table semantics (unlike changing the display attribute), though maybe also because the thead's role was kinda negligable anyway: so long as we had column headers above cells, screen readers did the Right Thing and it worked with nearly everything else (low-vision zooming is another instance where, for example, I cannot use any online Excel sheets because of excessive stickiness, and Google Sheets with anything sticky means I'm lucky to see more than 1 column at best).

A sticky row-header column may not work as nicely as an entire thead, but if it hasn't been tried, you could try it and see how it reads in AT. Otherwise the two-table thing is a pain in the butt but it has been used successfully in the past so long as the AT-hidden table does not need to be controls (re-orderable rows for example; checkboxes for selection may still work fine).

The idea of allowing users to choose whether to stick or unstick the column is excellent though, because as a browser zoomer this would benefit me greatly (sometimes I would like to see more than 1 or 2 columns at a time without sticky things stealing my limited screen real estate).

On Tue, Sep 17, 2019, at 1:06 AM, glen walker wrote:
> The "hacking" comment and using the roles was not specifying roles on
> elements that had the role already. When you specify role="presentation"
> on a table, all rows and cells lose their identities. When you're hacking
> two separate tables to appear as one table, you have to reapply the
> appropriate roles to the <tr> and <td> elements.

More like, nobody's adding role="presentation" but they are CSSing things like display: block. Unfortunately this also removes the default roles in many browsers (I'm not sure if all do this, but certainly Firefox and Safari have both done it for a very long time).

cheers
_mallory