[
https://issues.apache.org/jira/browse/TRINIDAD-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146897#comment-13146897
]
Jakub commented on TRINIDAD-1917:
---------------------------------
Confirming the problem. The blind person was not able to notice the table
change after navigating with pagination (he said it just disappeared). JAWS 10
and Window-eyes were used as screen reader software. Is there any workaround
for this issue?
> Accessibility Issues With Full Component Rendering
> --------------------------------------------------
>
> Key: TRINIDAD-1917
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1917
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 2.0.0-alpha-2
> Environment: Win XP 64-bit, FF 3.6, NVDA
> Reporter: Karel Simek
> Priority: Minor
>
> At this time whenever a component state changes (tab is clicked, accordion is
> expanded,..) the whole component gets removed from the DOM tree, re-created
> and re-inserted back again. This isn't the best solution but seems to be ok.
> The are however (hidden) issues with this design when using a screen reader
> to operate such a component.
> 1. Since the component is recreated as a whole, the assistive technology
> cannot determine that the newly inserted component is in fact the same
> component just within a different state. The result is that every time the
> component is used, the whole path to the focus is repeated
> Choosing a tab reads:
> document
> table
> row 1 column 2
> tab control
> Houses tab selected 3 of 5
> istead of: "Houses tab selected 3 of 5"
> The output get even more verbose and confusing on real websites as there are
> more components and deeper structures then in my testing scenarios.
> 2. Second issue with the currect architecture is that ARIA live-regions do
> not work. Live regions are contained within the component body and mark parts
> of the component that are going to change. But since the WHOLE component is
> removed, there are in fact no changes to the live-regions and the user is
> left to hide-and-seek strategy to determine what changed. That is what we
> dont' want.
> Components affected:
> Accordion Panel
> Panel Choice
> Panel Radio
> Panel Poppup
> PAnel Tabbed
> Progress Indicator
> Status Indicator
> Select Range
> Table Pagination
> Mavigation Tree
> Tree
> To see this behaviour, check my work on Accessible Trinidad at
> http://gf.felk.cvut.cz:8080/trinidad/faces/PanelTabbed.jspx
> Use NVDA screenreader and try out the TabPannel demo. My idea was to have
> JavaScript logic attached to the component and based on performed operation
> (hide accordion segment, select tab 3) perform component update and move
> focus. Would that be possible? Any ideas to help with this?
> The bottom line is that having a partial rendering would enable Trinidad be
> more accessible as in fact this is the only design change I have found to be
> needed to support ARIA within Trinidad. Really.
>
> Cheers,
> Karel Simek
> CoE Team
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
