If a use case extends another is independent from the visible associations between actors and use cases. However, whenever there is an actor associated with a use case like "checkout items", it is clear this situation requires user interaction, which makes it mandatory to have a viewing feature part of that use case, not the other way round.
Therefore, I heavily recommend not to model "view items" as a use case on its own. An employee does not view items "just for fun", for real use cases, there should be a business purpose behind it. Some examples, which all will need this viewing feature:
checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"
given those items have a price, then "paying an item" might be a use case
"checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings)
UML use case notation is intended for describing usage scenarios mostly independend from the UI. This notation and the "extends" and "includes" relationships are designed for a higher level of abstraction. Even if the use case "checkout items" will be started at the user interface by viewing the items first, that is nothing I would try to express through the model, it is just an UI detail.
If you still feeel urged to model "view items" as a separate use case, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, it is IMHO obvious that most use cases involving user interaction with items need a viewing feature: users don't want to poke around with items blindly when operating on them.