I used it once. It ain't pretty, but it is possible to use it.
Your important resources are the Help Authoring program, MS Word, and Access.
You must first design how you want your files laid out. You will have two possible divisions of the help file to work with.
First, you can have the traditional tree that starts with little closed-book symbols. As you click them, you reveal either more little books or the individual help pages. For this, you must draw the tree ahead of time.
Second, you can have help linked directly to controls on your forms. The links are in the HelpContextID property (under "Other") in each control's property sheet. When you press SHIFT+F1, you get the "What's This" cursor, which is a pointer and a big question mark. When you click on the control, the associated help text comes up. For this, you must make a list of the fields for which this will be used. There is no requirement that direct-link help text has to also appear in the "book tree" section. In other words, they can be totally disjoint sections that appear in a single file.
OK, the Word file contains your help text. You must make it somewhat ugly, I'm afraid. It will be hard to read as regular file just because it could contain some disjoint topics that are in odd juxtaposition with each other. But, c'est la vie!
Add a bold header and one or normal text paragraphs (as a help "unit") for each help topic you want to see either as a final page in the "book tree" section or as a page in the direct-link help section.
Your file will look like a bizarre sequence of
Section Header Text 1
Section 1 text
Section Header Text 2
Section 2 text
and so on.
Now put the Word cursor at the beginning of each header line. You will probably have more than one footnote to add to each topic. You create footnotes based on special characters that define the title, topic identifier, and window type. This is a very tedious but absolutely necessary step.
When you are done editing, save this twice. Once as a Word document, which should be kept as your master copy for future updates, and once in .RTF format, which is the required input for the help editor.
Now, open notepad. You created topic identifiers in the help file. Now you have to assign them numbers in an "INCLUDE" file of type .INC - it just a list of lines with
# define topic-name context-number
for every topic-name, whether or not that topic is to be referenced using the What'sThis pointer. Assign unique numbers to ALL topics.
You have to create a CONTENTS (.CNT) file. This defines the tree structure. Your choices will be to subdivide the tree into more "closed book" symbols or to open a page with a section of the help file. You'll have to come up with unique context names for the "closed book" symbols that don't overlap with any context name you created in the Word document.
Now, compile the mess. Refer to the manuals or help files as to how to actually identify the files in their proper context. If you have TEFLON spray, apply it to your hair liberally, because this is the part where you will want to tear your hair out in clumps. The TEFLON will protect you from yourself here.... (just kidding, but only kidding a little bit).
Finally, you can go back to Access armed with a copy of your INCLUDE file. For each topic you have identified as being called with a What'sThis pointer, insert the code number into the HelpContextID field.
The default for HelpContextID is 0, and that can't be a valid context ID, so if you use a What'sThis on something that lacks a separate context ID, you'll get the default Access Help topic for Forms.
Now don't forget that the forms have to point to the Help File with a complete path and name, so you have to insert this data into the HelpFile property of the form itself.
The messier the help file, the more likely you will be to want to find alternatives. However, once you get it right, it is much easier to maintain. So despite the true ugliness of the initial creation of a help file, there IS a light at the end of the tunnel. And I don't THINK it is an onrushing train.
