dojo ui help

[Richard Schwerdtfeger]

I agree with that for text. ... but not for a widget. Widgets you would
like to amphasize should have a convention of drawing a border around it to
draw attention. So, in these instances you would trigger off an element
property:

role, id, etc.

Rich,


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             Michael S Elledge                                             
             <elledge at msu.edu>                                             
             Sent by:                                                   To 
             fluid-work-bounce         David Bolter                        
             s at fluidproject.or         <david.bolter at utoronto.ca>          
             g                                                          cc 
                                       fluid-work at fluidproject.org         
                                                                   Subject 
             07/11/2007 12:27          Re: dojo ui help                    
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi all--

I may be misunderstanding this, but if highlighting is being used to
increase emphasis or attention to an item, you should indicate that
using the <em> or <strong> elements in HTML. How it appears,
highlighted, in bold, whatever, can be controlled using CSS. If you do
it this way a screen reader will let the user know what you're up to.

Mike

David Bolter wrote:
> Colin,
>
> Thanks for your reply, it was right on topic, and thanks for checking
> the Apple docs. This is a bit of a mucky one I think.
>
> I've spent a bit of time away from dojo and am not sure but I think Bill
> is struggling with how to capture the semantics of highlighted in
> perhaps a style-agnostic term. It might be futile :)
>
> I've seen, and experienced first hand, confusion over the various states
> that different toolkits have... stuff like armed, active, selected,
> checked, enabled, pressed, on...
>
> The aria state documentation is quite descriptive... but I'm not seeing
> anything that fits say a highlighted parent menu item. I'm not sure a
> semantically meaningful term for this is a good idea or not... but worth
> exploring. If a menu-item is selected/armed/active/highlighted we might
> contort our minds to think of that as a temporary live region and the
> related parent menu item as 'relevant' but I really don't want to go
there.
>
> I think *maybe* menu items that open submenus should have a selected
> state if a user has selected them. Tomorrow I may disagree with myself.
> It does seem to diverge a bit from the typical use of the selected state.
>
> cheers,
> D
>
> Colin Clark wrote:
>
>> Hi David,
>>
>> So, in this case, the thing you're suggested Fluid can help with is
>> Bill's question about what highlight/hover state should be called? Or
>> am I confused?
>>
>> I did a quick read through the Apple Human Interface Guidelines, just
>> as an example of where this terminology might be mentioned, and didn't
>> find any reference to it.
>>
>> How about calling it "highlighted"? :)
>>
>> Does anyone else know if there is established terminology for this
>> behaviour menus?
>>
>> Colin
>>
>> David Bolter wrote:
>>
>>> This is an example of the kind of thing I hope the FLUID ui gurus can
>>> help with if possible:
>>>
>>>
http://dojotoolkit.org/forum/developer-forums/dijit-development/toolbars-menus-and-selection

>>>
>>>
>>> I understand it may be too early to commit to a toolkit; and to
>>> commit resources to a toolkit.
>>>
>>> cheers,
>>> D
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at fluidproject.org
>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>
>
>
(See attached file: elledge.vcf)
_______________________________________________
fluid-work mailing list
fluid-work at fluidproject.org
http://fluidproject.org/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070711/c89e5914/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070711/c89e5914/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic04656.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070711/c89e5914/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070711/c89e5914/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: application/octet-stream
Size: 2 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070711/c89e5914/attachment.obj>