E-mail List Archives

Search E-mail List Archives for

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

From: Sumit Patel
Date: Wed, May 24 2023 4:38AM
Subject: Inaccessible table
No previous message | Next message →

Hai,

I have a table which has column headers , row headers and tooltips
inside most of the cells.
When A screen reader user navigates on this table with arrow keys ,
would not get to know anything as the reading order is completely
incorrect.
On arrow key, first focus goes to the row headers, then , column
headers , tooltips and finally to the cells .
Table structure is not get identified . so, the don't even know this
is a table unless a sighted user explains the structure

Seems like The dev team does not able to provide table structure as
they have technical limitation to make changes on this component .

So, they have given a PDF file next to this table which serves the ame
purpose . The pdf file is accessible .

So, my question is is it enough to meet WCAG ? because though the
information can be conveyed to screen reader user in an accessible
alternative , screen reader user will have a feeling that they are
missing something when the reader read out all the information in the
above given order .

Do we need to ask to hide the table from screen reader and provide a
a short alt text for the same and informing them an accessible
alternative is provided in the form of pdf below .

Regards,
Sumit.

From: Birkir R. Gunnarsson
Date: Wed, May 24 2023 5:30AM
Subject: Re: Inaccessible table
← Previous message | Next message →

The tagged PDF falls under the W3C definition of conforming
alternative, (as long as you can link directly to it from the page
with the inaccessible table and it has all the same info as the table,
which appears to be the case here).
The content order issue with the table is troublesome nevertheless.
Does the table contain focusable elements, like buttons? If so hiding
it from screen reader users with aria-hidden="true" is not really an
option.
If it does not have focusable elements, then you can hide it that way
and offer up the PDF as an alternative.
If it does you may need to add a button to switch between table view
and link to the PDF file for all users.
Finally, there should be a way to fix the table and code it properly
or work around it with ARIA, the team may just need more guidance
onhow to do that.
Without seeing the actual source code I cannot offer up an opinion on ow.




On 5/24/23, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
> Hai,
>
> I have a table which has column headers , row headers and tooltips
> inside most of the cells.
> When A screen reader user navigates on this table with arrow keys ,
> would not get to know anything as the reading order is completely
> incorrect.
> On arrow key, first focus goes to the row headers, then , column
> headers , tooltips and finally to the cells .
> Table structure is not get identified . so, the don't even know this
> is a table unless a sighted user explains the structure
>
> Seems like The dev team does not able to provide table structure as
> they have technical limitation to make changes on this component .
>
> So, they have given a PDF file next to this table which serves the ame
> purpose . The pdf file is accessible .
>
> So, my question is is it enough to meet WCAG ? because though the
> information can be conveyed to screen reader user in an accessible
> alternative , screen reader user will have a feeling that they are
> missing something when the reader read out all the information in the
> above given order .
>
> Do we need to ask to hide the table from screen reader and provide a
> a short alt text for the same and informing them an accessible
> alternative is provided in the form of pdf below .
>
> Regards,
> Sumit.
> > > > >


--
Work hard. Have fun. Make history.

From: Dean.Vasile@outlook.com
Date: Wed, May 24 2023 5:32AM
Subject: Re: Inaccessible table
← Previous message | Next message →

I am curious.
Are you pressing Alt+control+left and right arrow?

Dino

617-799-1162

Dino's Canteen 1618
11 Eglin St,
Hanscom AFB
Bedford, MA

> On May 24, 2023, at 6:38 AM, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hai,
>
> I have a table which has column headers , row headers and tooltips
> inside most of the cells.
> When A screen reader user navigates on this table with arrow keys ,
> would not get to know anything as the reading order is completely
> incorrect.
> On arrow key, first focus goes to the row headers, then , column
> headers , tooltips and finally to the cells .
> Table structure is not get identified . so, the don't even know this
> is a table unless a sighted user explains the structure
>
> Seems like The dev team does not able to provide table structure as
> they have technical limitation to make changes on this component .
>
> So, they have given a PDF file next to this table which serves the ame
> purpose . The pdf file is accessible .
>
> So, my question is is it enough to meet WCAG ? because though the
> information can be conveyed to screen reader user in an accessible
> alternative , screen reader user will have a feeling that they are
> missing something when the reader read out all the information in the
> above given order .
>
> Do we need to ask to hide the table from screen reader and provide a
> a short alt text for the same and informing them an accessible
> alternative is provided in the form of pdf below .
>
> Regards,
> Sumit.
> > > >

From: tim.harshbarger@deque.com
Date: Wed, May 24 2023 6:08AM
Subject: Re: Inaccessible table
← Previous message | Next message →

I would also make sure that the PDF is clearly indicated as an accessible alternative to the table. And the accessible alternative should be visible so anyone can access it.

I am less certain I might hide the table from screen readers. There are people with disabilities who can see but use screen readers or technologies like screen readers. Hiding the content from a screen reader may impact their user experience as well.

Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, May 24, 2023 6:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Inaccessible table

The tagged PDF falls under the W3C definition of conforming alternative, (as long as you can link directly to it from the page with the inaccessible table and it has all the same info as the table, which appears to be the case here).
The content order issue with the table is troublesome nevertheless.
Does the table contain focusable elements, like buttons? If so hiding it from screen reader users with aria-hidden="true" is not really an option.
If it does not have focusable elements, then you can hide it that way and offer up the PDF as an alternative.
If it does you may need to add a button to switch between table view and link to the PDF file for all users.
Finally, there should be a way to fix the table and code it properly or work around it with ARIA, the team may just need more guidance onhow to do that.
Without seeing the actual source code I cannot offer up an opinion on ow.




On 5/24/23, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
> Hai,
>
> I have a table which has column headers , row headers and tooltips
> inside most of the cells.
> When A screen reader user navigates on this table with arrow keys ,
> would not get to know anything as the reading order is completely
> incorrect.
> On arrow key, first focus goes to the row headers, then , column
> headers , tooltips and finally to the cells .
> Table structure is not get identified . so, the don't even know this
> is a table unless a sighted user explains the structure
>
> Seems like The dev team does not able to provide table structure as
> they have technical limitation to make changes on this component .
>
> So, they have given a PDF file next to this table which serves the ame
> purpose . The pdf file is accessible .
>
> So, my question is is it enough to meet WCAG ? because though the
> information can be conveyed to screen reader user in an accessible
> alternative , screen reader user will have a feeling that they are
> missing something when the reader read out all the information in the
> above given order .
>
> Do we need to ask to hide the table from screen reader and provide a
> a short alt text for the same and informing them an accessible
> alternative is provided in the form of pdf below .
>
> Regards,
> Sumit.
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Sumit Patel
Date: Wed, May 24 2023 6:28AM
Subject: Re: Inaccessible table
← Previous message | Next message →

alt + ctrl + arrowkeys won't work here as screen reader does not
identify it as table. just using arrow keys - down and up arrow .

We have given use aria table as a solution. but, their response was
the component code is not in their control . so, they can't these many
attributes on that . So, they have given this pdf file to confirm with
WCAG.

Coming back to the trouble or confusion which is going to be faced by
screen reader users regarding the table, is it goinggoing to violate
any sc of WCAG or just going to be a best practice

I am sure this approach not going to give a good user experience for them

On 24/05/2023, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> I would also make sure that the PDF is clearly indicated as an accessible
> alternative to the table. And the accessible alternative should be visible
> so anyone can access it.
>
> I am less certain I might hide the table from screen readers. There are
> people with disabilities who can see but use screen readers or technologies
> like screen readers. Hiding the content from a screen reader may impact
> their user experience as well.
>
> Thanks!
> Tim
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Wednesday, May 24, 2023 6:31 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Inaccessible table
>
> The tagged PDF falls under the W3C definition of conforming alternative, (as
> long as you can link directly to it from the page with the inaccessible
> table and it has all the same info as the table, which appears to be the
> case here).
> The content order issue with the table is troublesome nevertheless.
> Does the table contain focusable elements, like buttons? If so hiding it
> from screen reader users with aria-hidden="true" is not really an option.
> If it does not have focusable elements, then you can hide it that way and
> offer up the PDF as an alternative.
> If it does you may need to add a button to switch between table view and
> link to the PDF file for all users.
> Finally, there should be a way to fix the table and code it properly or work
> around it with ARIA, the team may just need more guidance onhow to do that.
> Without seeing the actual source code I cannot offer up an opinion on ow.
>
>
>
>
> On 5/24/23, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>> Hai,
>>
>> I have a table which has column headers , row headers and tooltips
>> inside most of the cells.
>> When A screen reader user navigates on this table with arrow keys ,
>> would not get to know anything as the reading order is completely
>> incorrect.
>> On arrow key, first focus goes to the row headers, then , column
>> headers , tooltips and finally to the cells .
>> Table structure is not get identified . so, the don't even know this
>> is a table unless a sighted user explains the structure
>>
>> Seems like The dev team does not able to provide table structure as
>> they have technical limitation to make changes on this component .
>>
>> So, they have given a PDF file next to this table which serves the ame
>> purpose . The pdf file is accessible .
>>
>> So, my question is is it enough to meet WCAG ? because though the
>> information can be conveyed to screen reader user in an accessible
>> alternative , screen reader user will have a feeling that they are
>> missing something when the reader read out all the information in the
>> above given order .
>>
>> Do we need to ask to hide the table from screen reader and provide a
>> a short alt text for the same and informing them an accessible
>> alternative is provided in the form of pdf below .
>>
>> Regards,
>> Sumit.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> >
> > > > >

From: tim.harshbarger@deque.com
Date: Wed, May 24 2023 7:36AM
Subject: Re: Inaccessible table
← Previous message | Next message →

I am not aware of any WCAG success or conformance criteria that require that the inaccessible content be concealed or hidden. I believe the relevant conformance criteria just require that, if the content cannot be made accessible, an accessible alternative is provided, clearly marked as an accessible alternative, and exists on the same page.

There are a handful of success criteria where it is not allowed to provide an accessible alternative. However, this is not one of those situations.

Personally, I am always a bit reluctant to hide content from screen reader users. While there are people with visual impairments who only use a screen reader, there are also people with disabilities who can see and use a screen reader. For those people, the original table may not be so inaccessible since they will be seeing and listening to the information. However, everything in this paragraph is just a personal opinion--so is definitely not necessary to follow to conform with WCAG.

If I erred regarding any of the WCAG requirements, I am sure one of our other knowledgeable experts will chime in and help clarify what is necessary for WCAG conformance.

Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Wednesday, May 24, 2023 7:29 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Inaccessible table

alt + ctrl + arrowkeys won't work here as screen reader does not identify it as table. just using arrow keys - down and up arrow .

We have given use aria table as a solution. but, their response was the component code is not in their control . so, they can't these many attributes on that . So, they have given this pdf file to confirm with WCAG.

Coming back to the trouble or confusion which is going to be faced by screen reader users regarding the table, is it goinggoing to violate any sc of WCAG or just going to be a best practice

I am sure this approach not going to give a good user experience for them

On 24/05/2023, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> I would also make sure that the PDF is clearly indicated as an
> accessible alternative to the table. And the accessible alternative
> should be visible so anyone can access it.
>
> I am less certain I might hide the table from screen readers. There
> are people with disabilities who can see but use screen readers or
> technologies like screen readers. Hiding the content from a screen
> reader may impact their user experience as well.
>
> Thanks!
> Tim
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Wednesday, May 24, 2023 6:31 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Inaccessible table
>
> The tagged PDF falls under the W3C definition of conforming
> alternative, (as long as you can link directly to it from the page
> with the inaccessible table and it has all the same info as the table,
> which appears to be the case here).
> The content order issue with the table is troublesome nevertheless.
> Does the table contain focusable elements, like buttons? If so hiding
> it from screen reader users with aria-hidden="true" is not really an option.
> If it does not have focusable elements, then you can hide it that way
> and offer up the PDF as an alternative.
> If it does you may need to add a button to switch between table view
> and link to the PDF file for all users.
> Finally, there should be a way to fix the table and code it properly
> or work around it with ARIA, the team may just need more guidance onhow to do that.
> Without seeing the actual source code I cannot offer up an opinion on ow.
>
>
>
>
> On 5/24/23, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>> Hai,
>>
>> I have a table which has column headers , row headers and tooltips
>> inside most of the cells.
>> When A screen reader user navigates on this table with arrow keys ,
>> would not get to know anything as the reading order is completely
>> incorrect.
>> On arrow key, first focus goes to the row headers, then , column
>> headers , tooltips and finally to the cells .
>> Table structure is not get identified . so, the don't even know this
>> is a table unless a sighted user explains the structure
>>
>> Seems like The dev team does not able to provide table structure as
>> they have technical limitation to make changes on this component .
>>
>> So, they have given a PDF file next to this table which serves the
>> ame purpose . The pdf file is accessible .
>>
>> So, my question is is it enough to meet WCAG ? because though the
>> information can be conveyed to screen reader user in an accessible
>> alternative , screen reader user will have a feeling that they are
>> missing something when the reader read out all the information in the
>> above given order .
>>
>> Do we need to ask to hide the table from screen reader and provide a
>> a short alt text for the same and informing them an accessible
>> alternative is provided in the form of pdf below .
>>
>> Regards,
>> Sumit.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >

From: glen walker
Date: Wed, May 24 2023 8:19AM
Subject: Re: Inaccessible table
← Previous message | Next message →

It sounds like the HTML "table" is just a series of divs/spans with no real
table related roles and that keyboard event handlers are allowing the arrow
keys to navigate.

In general, it's much easier to make an HTML table accessible than it is to
make a PDF table accessible. The PDF is typically generated from another
file (Word doc, design doc, etc) but those other files typically have
minimal support for creating accessible content so you often have to
manually remediate the PDF to make it accessible. If any contents of the
table have to change, you have to do that process all over.

I understand your html table comes from a third party vendor and you don't
have control over changing it but speaking as a developer myself, there are
sometimes ways to work around that. First you have to check the
documentation of the component carefully because there might be ways of
improving its accessibility. Sometimes I have been able to "post-process"
the generated HTML code and could inject ARIA into the generated code. It
wasn't ideal, but it helped.

Your main question was "is it good enough to have an accessible
alternative?". Yes, it's "good enough" to pass WCAG but that's only if
your main concern is passing a minimal baseline.

From: Birkir R. Gunnarsson
Date: Wed, May 24 2023 8:50PM
Subject: Re: Inaccessible table
← Previous message | No next message

Agreed, hiding the table is not ideal, perhaps put it in a region
element with aria-label="table" and have a comment right above it
pointing to the PDF as an alternative. Then the inaccessible table
boundreis are clear on the page and the screen reader user can jump
past it if they want.
And, yes, if the table is dynamic or if the ddata ever changes, the
alternative must be updated to match, which is problematic for
maintenance and ensuring equitable experience for all users.


On 5/24/23, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> It sounds like the HTML "table" is just a series of divs/spans with no real
> table related roles and that keyboard event handlers are allowing the arrow
> keys to navigate.
>
> In general, it's much easier to make an HTML table accessible than it is to
> make a PDF table accessible. The PDF is typically generated from another
> file (Word doc, design doc, etc) but those other files typically have
> minimal support for creating accessible content so you often have to
> manually remediate the PDF to make it accessible. If any contents of the
> table have to change, you have to do that process all over.
>
> I understand your html table comes from a third party vendor and you don't
> have control over changing it but speaking as a developer myself, there are
> sometimes ways to work around that. First you have to check the
> documentation of the component carefully because there might be ways of
> improving its accessibility. Sometimes I have been able to "post-process"
> the generated HTML code and could inject ARIA into the generated code. It
> wasn't ideal, but it helped.
>
> Your main question was "is it good enough to have an accessible
> alternative?". Yes, it's "good enough" to pass WCAG but that's only if
> your main concern is passing a minimal baseline.
> > > > >


--
Work hard. Have fun. Make history.