You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Karel Simek (JIRA)" <de...@myfaces.apache.org> on 2010/09/15 12:23:33 UTC

[jira] Created: (TRINIDAD-1917) Accessibility Issues With Full Component Rendering

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 (hidden) issue with is that when using a screen reader to operate this 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 ideas 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
CoE Team


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.