My impression is that you can, if you'd like, contact the author and see if they would be interested in the change. They will likely want to have an idea of what sort of changes you want to make and will probably want a small example of the refactoring. This is assuming they are even open to the idea. They may have reasons (good or bad) for doing things the way they are currently doing them, e.g. performance, essentially ideological preferences, or their own comfort with the techniques you want to use. Even if they agree with you that your changes could be beneficial, the project may be in a stable state where a "if it's not broken, don't fix it" attitude is not unreasonable. There is a chance that they will offer to add you as a maintainer, or even offer to have you become the maintainer, if they aren't particularly keen on being responsible for the code and they believe you are willing and able to take the responsibility. This likely won't happen immediately though.
The above is necessary if you want the current maintainers to take your changes into their version. It's not necessary if you don't particularly care about that. In that case, you can just make a fork and do whatever as long as the license allows it. If the fork is primarily for your own personal use, they probably won't even be aware of it. If you promote it as an alternative to the original library, then the original maintainers will probably not be happy if you didn't communicate with them beforehand, and may not be happy either way (though that will probably be obvious ahead of time if you communicated with them beforehand). That said, as long as you follow the terms of the license, they can't stop you. Third-parties may also be unhappy with unnecessary forking as it adds noise to the ecosystem making it harder to find quality, maintained libraries.
On the other hand, it's unclear why you even want to do this. It largely comes off as you just don't like the way they coded it, and you would've done it differently. I don't see why this should matter to you as a consumer. Technically, a refactoring is a semantics preserving change, and thus if your changes were really refactorings it would make no difference to any downstream consumers. However, I suspect you are using the term in a broader sense, and what you really want is a different API for the library. It may well be possible to do this as a wrapper around the existing library in which case there is no need to coordinate with the current maintainers and the maintenance burden on you for the wrapper will likely be significantly less.