There definately seems to be some confusion as to the difference between an
applet (a small application which runs in a browser) and an
Applet (a class with a few particular methods which can be called by the an applet container in a browser). You mentioned initially that you have three applets (a1, a2, a3), but from looking at your code it seems much more likely that you have one applet comprising three classes. the class CCYTable (a2) is not an Applet, and although ExplanatoryText (a3) is marked as an Applet, you seem to create it in your own code rather than letting the applet container in the browser manage it.
Most applets that you see on a browser screen consist of lots of objects of different classes working together. Only one of the classes is an Applet, and that is the "entry point" class mentioned in the HTML. If you have worked with command-line Java programs in the past, this is equivalent to the class which has the "main" method. The rest of the classes can be considered as "helper classes" or "business logic". These other classes are the ones that do the work of the system. The actual class marked as an Applet is mainly there so that the browser has "init", "start", "stop", and "destroy" methods to call.
When the Applet Container in a browser sees HTML indicating that an applet is present, it creates an instance of that class by calling a constructor with no arguments, then calls the init() method. When the browser is ready to run the applet it calls the start() method, if it needs to stop ths applet (for example because the user has navigated to a different page) it calls the stop() method. When the browser has finished with the applet (for example when the browser window is closed) it calls the destroy() method.
Note that because the applet container always calls a constructor with no arguments, any of your Applet constructors which take arguments will never be called. If you mark a class an Applet, but don't provide a constructor with no arguments it is unlikely to work at all.
Typically the actual code in an Applet class is kept quite short. Create a few objects of the helper classes in init(), maybe pass in a few parameters from the applet context. Then make calls to methods of these created objects in the rest of the lifecycle methods.
You should not put any code in the constructor. Anything you would normally do in a construct you should really consider doing in init() instead.
I'm guessing that the class TopLvlMenu is the actual Applet, the only one that you mention in your HTML (I'd still like to see the HTML snippet where you reference these applet(s), to make sure of all this). If so, this is the only one that the browser will manage, and therefore the only one that will have its "init" method called. All the other classes in this system are just regular Java helper classes, created and managed by your own code. They won't have an "init" method called by the container; they won't have access to any data in the applet context unless things are passed in to them from the Applet.
Good practice would suggest that we get url when and where it is needed i.e. at a3, ExplanatoryText.java I'm not sure I agree with this. In general, if a value is complicated or expensive to retrieve it makes sense to retrieve it only once, and share the value. Passing a String value to a method is something Java finds very easy to do, fetching the codebase may involve all sorts of difficult things including communicating with a containing browser or even back to the server.
This is especially true in this case, as (as far as I can tell) the class ExplanatoryText is only marked s "extends JApplet" is so that you don't get a compiler error when you call getCodeBase(). This should be hinting to you that ExplanatoryText is not really an Applet, just a "helper class", and that calling getCodeBase() won't get you any useful information anyway.
Did that make any sense?