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

[Justin Obara]

Just wanted to clarify why there are two views. The "code view" is  there to provide an easy to  read view of the code, hence the syntax highlighting and line breaks. The "plain text" view is intended for people to copy and paste  from. If you were to copy and paste from the "code view" it would include the line numbers.

- Justin
On 2010-10-22, at 3:47 PM, E.J. Zufelt wrote:

> 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
> 
> _______________________________________________________
> 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: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20101025/c559d28c/attachment.htm>