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

[Joseph Scheuhammer]

  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) -