Flare 9 compiled help is not the same as it was in Flare 8

[alex]

Hello all,
I noticed a number of problems after compiling an HTML5 target in Flare 9.1 in a project that compiled beautifully in Flare 8.1.

DifferencesInHelpCompiledUsingFlare8and9.png

Our dropdowns and togglers displayed as single-spaced items in v.8.1.
In v.9.1, vertical space is added between the dropdown and toggler headings, and there is a tooltip displaying now when I rest the pointer over the dropdown or toggler heading.

I haven't changed anything or done anything different in the v.9.1 version (and I really, really, really mean that I did NOTHING but open the same project in Flare 9.1, compile the help, and then notice that the dropdowns and togglers are now all messed up).

I'll enter a bug.

Has anyone else experienced this? I'm previewing using IE 9.

[alex]

FWIW, my manager figured out that the "Drop Down" tooltip that now displays may be related to the new accessibility feature enhancements introduced in Flare 9.

We looked in the compiled source code and found the tooltip text here:

Code: Select all

<div class="MCDropDown MCDropDown_Open dropDown "><span class="MCDropDownHead dropDownHead "><span class="MCDropDownHotSpot dropDownHotspot  MCDropDownHotSpot_" title="Drop Down">Student ID</span></span>
            <div class="MCDropDownBody dropDownBody ">
                <p>The student's ID number.</p>
            </div>

How can we change title="Drop Down" to not display anything?

We just want to turn it off.

Thanks!

[RamonS]

I know my post doesn't help, but why do you want to turn it off? Enhancing accessibility will make it easier for more people to use your help. I've worked with several visually impaired people who were going nuts because stuff like this was not supported - and they did the same work with the same excellence as their not impaired coworkers. My suggestion would be to turn anything that enhances accessibility on and optimize it.

My only idea to do what you want would be a global find and replace which searches for title="Drop Down" and replaces it with nothing (means removes it). The problem is that you would need to do this after each build.

[alex]

I don't make the decisions

How can we demonstrate how someone would experience these features?

If there are 20 dropdown fields in a help topic, would a reader tell you the name of each dropdown or just say, "drop down" because that is the default title?

Imagine a wall full of unlabeled light switches. You can run your hands along the wall, encounter each switch, and then have to actually flip the switch to find out which light it turns on... That's far less useful than touching the "porch light" switch to turn it on Know what I mean?

And, no, doing a mass FAR on "title=Drop Down" in the output is NOT an acceptable solution. We will need to go back to v8.1 if this can't be handled better.

The other issue is the spacing between the headings - it's using the same files and styles, but the v9.1 compiler adds extra vertical space. What is causing this?

[RamonS]

Well, it is not a wall with switches, at first it is a wall. The label will indicate that this is a switch and based on that the switch can be operated. Accessibility features are usually desired, but often do not get (fully) implemented as it is extra work. Unless you find an option to switch this off in v9 the only two things to do are rolling back to v8 and submitting a feature request to MadCap, you can do that here: https://www.madcapsoftware.com/feedback ... quest.aspx

[alex]

Well, it is not a wall with switches, at first it is a wall. The label will indicate that this is a switch and based on that the switch can be operated. Accessibility features are usually desired, but often do not get (fully) implemented as it is extra work.

Right. What I was getting at was that there's a wall (the topic)... with a number of switches (dropdowns and togglers)... and the switches are all labeled "switch" (instead of "porch light" "kitchen fan" "hallway light"). If anything, it would make sense (for us) for the label to indicate "switch - porch light" where "switch" is describing the type of UI element I'm encountering and "porch light" is telling me that out of the 20 "switches" on the wall, I want to actually click that one (instead of having to click every "switch" and eventually find the right one).

This is the part where someone jumps in and offers me a link or three to show me the standards and how online help systems use those standards

I was asking if there was a way that we can demonstrate how this works for someone who uses accessibility features. We have not worked with this sort of functionality, and it has not been requested by our customer base (to the best of my knowledge, that is).

I get that it is useful to have accessibility features, but proving that it is useful for *us* to use them is the key here. Is the benefit of having every single dropdown and toggler heading displaying "Drop Down" when one rests the pointer over the heading greater than the distraction it is causing?

Unless you find an option to switch this off in v9 the only two things to do are rolling back to v8 and submitting a feature request to MadCap, you can do that here: https://www.madcapsoftware.com/feedback ... quest.aspx

Yes, I mentioned that we'll be going back to 8.1 if this isn't something that we can turn off. I entered a bug about the two issues going on here - 1) the ability to "turn off" the generic label; 2) the extra spacing that has been introduced between headings of dropdowns and togglers.

I can live with the "Drop Down" tooltip text displaying, if necessary, but I am not willing to allow Flare to mess with the spacing in my CSS.

Thanks for your input.

[rpa]

Has anyone found a solution or a workaround to switch off the tooltip? Or even better, a solution to link the text with the UI-Text?
Our Help is published in German and Italian, that's why the tooltip should be "translatable".

Thanks, patrick

[jasonsmith]

Hi Patrick
you could perform an XSLT transformation on your content htm files

<!-- basically an identity transformation here -->
<xsl:template match="/">
<xsl:apply-templates select="*"/>
</xsl:template>
<xsl:template match="node()|@*|comment()|processing-instruction()|text()">
<xsl:copy>
<xsl:apply-templates select="node()|@*|comment()|processing-instruction()|text()"/>
</xsl:copy>
</xsl:template>
<!-- this is the functional template for the purpose -->
<xsl:template match="span/@title">
<xsl:attribute name="title">
<xsl:value-of select="ancestor::span"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>

Note that this will change all your span title attributes.