R. 42661/ IE10, IE11, Chrome37, FF31: re-tested showcase > accordion demos, and no issues have been found.
Also, the CSS Source view issue is resolved.

ICEfaces 4 trunk r42671
Tomcat 7, all browsers.
Reopening because the QA accordion in ui:Repeat inside h:dataTable test is now failing. When selecting an inactive pane, the matching panes in the ui:repeat also become selected.
This issue does not occur when accordion is alone inside ui:repeat, or h:dataTable or ace:dataTable.
To reproduce:
Use test app located at http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion.
Navigate to Accordion in Repeat and Data table test.
In the first row, select an inactive pane.
Note that all matching panes in the same row become activated.

The problem is with the test page/app itself. It just wasn't visible before, because before this fix there was no script to expand the active index dynamically, but all the hidden input fields, holding the active index for each accordion, were being updated. There was just no visible clue that there was something wrong with the app. Another way to see it, is to replace the accordion component on the test page (accordionRepeatDataTbl.xhtml) for an ace:tabSet, as in the following markup:

<ace:tabSet id="accordion" clientSide="false" selectedIndex="#{accordion.activeIndex}">
	<ace:tabPane id="cPane" label="Calgary">
		<h:outputText id="outputTxt1" value="Calgary content"/>
	</ace:tabPane>
	<ace:tabPane id="vPane" label="Vancouver">
		<h:outputText id="outputTxt2" value="Vancouver content"/>
	</ace:tabPane>
	<ace:tabPane id="tPane" label="Toronto">
		<h:outputText id="outputTxt3" value="Toronto content"/>
	</ace:tabPane>
	<ace:ajax event="serverSideTabChange" />
</ace:tabSet>

The issue with the test page is also visible when using an ace:tabSet. The problem is that the activeIndex/selectedIndex is being bound to the 'accordion' variable, which is the variable declared in the outer h:dataTable, and not the variable declared in the inner ui:repeat. There's not even a variable declared in ui:repeat. So, all accordions inside ui:repeat are bound to the same outer variable, so when an active index is modified, all accordions bound to that property also have to update their active indexes. Also, the data collection is exactly the same for the h:dataTable and for the ui:repeat (accordionRepeatDataTblBean.accordions), which doesn't make much sense to me, but I'm not sure what was the original purpose of this test page. What I'm used to see with nested iterative containers is that there's a data object for for the outer container and a different data object for the inner container, each with their own variables. A similar test in the ace:tabSet test app follows this pattern. Please review this test page/app and make the necessary changes for it to work normally.

The QA test application has been updated as required and committed to http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion r39540. No issues are present.