As @Daniel has already said, Kanban is not prescriptive - it asks you to start with what you today - and make incremental changes to your process to improve flow.
On a slightly different note, Agile teams with not too much experience initially have this issue of team members not being able to pull - or self-assign - work, because they are too used to being told what to do. Even in longer running Kanban teams, young/ new team members not used to Kanban have the same problem. In most cases, at least for some initial period of time, the team - the PO, the Scrum Master or the Engineering Manager - and the team member themselves will jointly decide in a standup meeting what work can be taken up by that team member. This can continue until such team members feel confident enough or empowered enough to pull work whenever they are ready to start on the next one.
Finally, it is the reality for many small and medium teams that specific people become experts in specific modules of a software they have built and maintain - or have specific technology skills such as front-end, backend database or some such skills. The PO and the team have no alternative but to wait for the right set of people to be available to work on tasks that need those skills.
As a Kanban-based dev shop, we do what you have outlined. We populate the Ready column with the next set of the highest priority/ business value items - and whenever the team members who are to (and can) work on those items become available, they will pull those items.
As for the team members who don't have skills to do the next set of items sitting in the Ready queue, whether your WIP Limit has been reached or not is a moot point. They just can't work on those tasks because they don't have the skills. They can either work on some intangible (class of service) work - such as some refactoring of code, perhaps documentation, or some such work - or ask the PO to identify something new they CAN do, since sitting idle is usually not an option. Here's a board design by class-of-service that you might consider -
In the meantime, as a team, as @Daniel suggested, you have to work on cross-training of team members so you reduce your people-dependency to some extent, and enable more people to take on more kinds of work that they would typically not consider to be "their work".