the contentNavBar would not require a disabled -that would be in the contentMenuItem child of the component, which does have a disabled attribute.
Not sure how a "disabled" attribute would pertain to carousel or qrscan??
The carousel is typically a layout. If there is a link button within the carousel element/item, then the disabled should be on that element/component. Reviewing the carousel component, we should probably implement a carouselItem (an optional child component within the carousel that can have disabled attribute).

svn rev 31805. Fixes for fetchContact, inputText, and qrscan have been checked in.

Accordion, carousel, and tabSet still need doing.

panelPopup testing completed in mobitest an dpassing panelPopup rev 32647

many of these are done (accordion, carousel, tabSet)...but these will be completed when core rendering strategy is done for each component. Propose to close this one and have a jira for each component that is to use core rendering and then place the requirement for disabled with definition there.
For example, just completed audioPlayer and videoPlayer and there is no html5 property of disabled on either of the html5 elements that these represent (possibly could use muted property??)..so doesn't always equate. Each component must be determined on it's own.

see last comment. As components are brought into core rendering strategy, this will be addressed.