I recently implemented a* in a game I'm working on in JavaScript, so I thought I'd try my best to answer your question. The path finding is functional in the Ludum Dare build and you can search for "findPath =" in the JavaScript file if you want to see my implementation, but it is custom for my game.
The basic idea of a* is that you have several possible positions that something can be in, each being connected to those near it, forming a web. In a lot of cases, this is a grid of some sort. a* is then able to find the shortest path from a starting position to a destination, if there is one, and try to do so quickly by guessing roughly how far a step will be from the destination using a heuristic before actually testing it. More possible positions will use up more memory and need more processing time. I could explain a* in more detail, but you're just as well off doing a search to learn more.
From how you have phrased your question, it sounds like you want to create a path using images that have been drawn to a Canvas (you can correct me if I'm wrong). Unless you are only drawing collision-useful images to the Canvas, this isn't a practical approach. You will likely want to be keeping track of player positions and collision information somewhere else. Path finding is not related to the way that you are displaying an image to a user, it's more about how you're storing collision and position data. A Canvas doesn't know anything about what you put on it aside from what everything looks like when it's done drawing.
Most a* implementations will give you a list containing steps. In the case of my game's implementation, it returns an array of grid indexes (y*width+x), in reverse order of when they should be traveled to. It's a fairly small tile-based game, so there aren't a lot of positions to check, and it skips checking empty or impassable tiles on the grid.
You can use this path to move your player character. Change its position to the next location in the path (if the distance between the points is long, you can always smooth it out a bit), wait a bit, then move it to the second location, and repeat. You should be redrawing the Canvas (or at least the parts that changed) whenever the player moves. Waiting can be done using a timeout or an interval, but rendering is generally best done using requestAnimationFrame because it waits until the user's monitor is ready to display the image.