What role and interaction for Code/Plain in demo portal?

E.J. Zufelt everett at zufelt.ca
Fri Oct 22 19:47:40 UTC 2010


I would add to this that if there is a good reason for two views that there needs to be a good reason for using a non-native xhtml control.  That is to say that radio / checkbox is preferable to tabs / toggle button.  This way the semantics of xhtml can be used without the need to rely on ARIA.  That being said, if the application is already ARIA dependent then this is less of an issue.


Everett Zufelt
Accessibility Consultant & Web Developer

Web
http://zufelt.ca
Phone (toll free U.S. & Canada)
1-877-ZUFELT-8 (1-877-983-3588)

Follow me on Twitter
http://twitter.com/ezufelt
View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



On 2010-10-22, at 3:34 PM, Joseph Scheuhammer wrote:

> On 21/10/10 2:50 PM, Cheetham, Anastasia wrote:
>> I'm trying to figure out what would be the proper ARIA role and keyboard interaction for these two options. Are they radio buttons? A toggle button? (Does ARIA even have a specific role for toggle buttons?) Are they tabs (within a tab)? just plain links that activate something?
> 
> *If* they are toggle buttons, there should be only one button.  The marked case here is "coloured syntax", so the label on the button is along the lines of "Coloured Syntax".  When pushed, the code is displayed with colour; when popped, without.  Also, it's important that the button really appear pushed in when toggled on.  Compare with a "bold" tool bar button in a word processor.
> 
> In terms of ARIA, there is no toggle button role.   Toggle buttons are achieved using the combination of a "button" role plus an "aria-pressed" state.  When aria-pressed is "true", the button is pushed, or toggled on.  When aria-pressed is "false", it's popped up.
> 
> Much the same effect is accomplished using a check box labelled "Coloured Syntax".  Here, either use an <input type="checkbox">, or roll your own with a an ARIA "checkbox" role plus "aria-checked" attribute.
> 
> *If* they are radio buttons, then there are two of them within a radio group.  The group label should be along the lines of "Coloured Syntax", with one radio button labelled "on", and the other "off".  Either use two <input type="radio"> with the same "name" attribute, or an ARIA "radio"  role plus aria-checked, and a containing element with a "radiogroup" role.
> 
> *If* they are tabs, then the entire area should be rendered as a standard tabbed pane, much like the enclosing html/css/js tabbed panel.  And, yes, tabs within tabs is used in some circumstances.  There are ARIA roles, states, and properties for tabs, tablists, tabpanels, and so on, but that's beyond the scope of this email.  That is, I'll address that if you do go with a tabbed pane UI.
> 
> *But*, I'd rewind and start from the beginning:  what is this UI for?  Why are there two views, one "plain text" and another "code view" (coloured syntax)?  Put another way:  why isn't a single coloured view of the code sufficient?  The colours provide information much like a code editor, and, if the reader is colour blind, the spatial formatting is clean enough to make out what's going on.  Note that I'm not saying that there isn't a good reason for the two views.  It's just that it's not obvious to me.
> 
> Also, if it's decided that a single view suffices, then it might be that how it's presented (colour vs. black-and-white) is handled as a presentation option, as James is suggesting.
> 
> -- 
> ;;;;joseph
> 
> 'Clown control to Mao Tse Tung.'
> - D. Bowie (misheard lyric) -
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20101022/6e45a680/attachment.html>


More information about the fluid-work mailing list