Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#5178 closed defect (wontfix)

TitlePane should use a different attachPoint for setting css

Reported by: nathan Owned by:
Priority: high Milestone:
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

TitlePane? is very difficult to extend and add additional buttons to its heading because the css state is set on focusNode instead of on the titleNode.

I suggest adding a new attach point (titleHeaderNode) and using it to set the CSS state. This allows subclasses to "move" the focus node to the arrow (if they desire - to make just the arrow "clickable") without messing up the css state.

Attachments (1)

patch.diff (1.4 KB) - added by guest 15 years ago.

Download all attachments as: .zip

Change History (10)

Changed 15 years ago by guest

Attachment: patch.diff added

comment:1 Changed 15 years ago by bill

Component: GeneralDijit
Description: modified (diff)
Owner: anonymous deleted

comment:2 Changed 15 years ago by bill

IIRC putting focus on the arrow messes up a11y, because the screen reader won't read the title, so I'd discourage you from doing that. Actually I'm surprised you are thinking about where the focus goes at all; why are you concerned about that?

comment:3 Changed 15 years ago by guest

I actually was thinking in terms of screen readers by moving the focus - focus, in my understanding, is meant to indicate the "clickable" or "widget" areas of the page. If you move the action of "collapsing" and "expanding" to the arrow node only, then the arrow node itself is the focus node (because that's the node that should be getting action).

The title node is no longer actionable - and therefore, no longer should get focus from the screen reader, tab keypress, or otherwise.

Also - a screen reader would correctly *not* read anything if the arrow node is the focus node....because the arrow node has no content. The title of the pane should be read regardless - (same as the body of the TitlePane?) - since it's content. However, when the arrow is the "actionable" item, screen readers should provide a "different" (possibly) value. For example, picture a subclass of TitlePane? with two buttons - one to collapse/expand, and one to remove. Each one of those nodes should be "focusable" and "actionable" - and they should have different screen reader values ("Close this pane" / "Collapse (or expand) this pane") - neither of which is the content of the title of the pane. This screen reader functionality would be left up to the person implementing a subclass of TitlePane?.

Again - this is only for subclassing purposes....the current behavior of TitlePane? itself would remain with this patch, since the focusNode and the titleHeaderNode are one and the same.

comment:4 Changed 15 years ago by Becky Gibson

Since this patch does not change the current functionality I have nothing against adding it although I don't really see the necessity. If someone is planning to extend the title pane title bar with additional buttons they can make this change at the same time.

However, I'm not sure I agree with requiring separate buttons to open/close and delete - they just add additional tab stops and I'm not sure how the user would know what was being opened/closed or deleted? There would be a fair amount of work to associate both the title pane title as well as the button text to the button so the screen reader would announce both. The tab panel handles this by associating the ctrl+w and delete keys to the action of deleting a closeable tab. There is still an issue of the user discovering that the tab is closeable but I believe that is preferable to adding an additional tab stop on each tab title just for deleting a tab. My two cents.

comment:5 Changed 15 years ago by guest

I don't know that extending TitlePane? to add more buttons to it is something that anyone is interested in adding to the dojo library itself. The main purpose of this ticket is just so that a third-party (me, for example), has the *ability* to extend TitlePane? - and move the focus node somewhere else.

In my opinion, the current logic behind _setCss function in TitlePane? is incorrect - the focusNode *isn't* the one that should have a change of CSS set on it...because the focusNode is important to a11y. It should be able to be moved to wherever makes sense by someone who is subclassing the widget. That is the *only* issue that this ticket (and patch) addresses.

The discussion of *how* to actually subclass (and what the best practices are, etc) are a separate one - this ticket is merely a request to allow the ability to move that node around.

comment:6 Changed 15 years ago by guest

I would like to withdraw this patch - it seems that there is some pushback on getting it changed - and a similar thing can be accomplished by moving around the attachEvents (rather than the attachPoints) in subclasses.

comment:7 Changed 15 years ago by bill

Resolution: wontfix
Status: newclosed

comment:8 Changed 14 years ago by nathan

Cc: nathan added; [email protected] removed

comment:9 Changed 14 years ago by nathan

Cc: nathan removed
Reporter: changed from guest to nathan
Note: See TracTickets for help on using tickets.