How can I build a website menu that works with both keyboard and pointer?

Usually, no. If those items are links to destinations on your website, build a conventional navigation list containing ordinary links. A site navigation structure is typically conveyed as a list, with ordinary links in the list; an unordered list is suitable when the order does not matter. [S1] Calling the design a “menu” does not by itself make it an application-style menu.

Keep the interaction appropriate to the task: users choose a destination, rather than issue a command inside an application. That distinction helps avoid adding widget behavior the interface does not need. The relevant pattern depends on what the controls do, not just their appearance.

First decide whether the panel is still navigation or is a collection of application-style commands. A panel containing more destinations can still be organized as navigation links; its visual appearance alone does not establish that it should use an application-menu pattern. [S1]

For a pointer-and-keyboard review, test the panel’s actual tasks rather than assuming one input method is enough. With a pointer, check that a person can reach and choose each destination and dismiss or move away from the panel as designed. With a keyboard, check that the same destinations can be reached and activated, and that a person can leave the panel and continue through the page. Write down the intended behavior first so the two tests can be compared. These are practical test prompts, not a substitute for checking the final implementation against the chosen pattern.

Use that pattern when the choices are genuinely menu commands or comparable application actions, rather than ordinary links to site destinations. The WAI-ARIA Authoring Practices describe menu widgets as collections of choices such as actions or functions, modeled on desktop application menus. They require managed focus and arrow-key navigation; Tab and Shift+Tab leave the menu instead of moving through its items. [S2]

That is a different interaction contract from a list of destination links, so adopting it adds keyboard behavior to implement and test. Don’t select it solely because the panel looks like a compact dropdown. The pattern descriptions establish that distinction and the menu widget’s listed keyboard model; they do not establish that a particular implementation is accessible, nor do they specify every detail of your site’s design.

Use this decision note as a copyable starting point:

Purpose: [destinations / application commands] Chosen pattern: [navigation list / application-style menu] Pointer tasks: [open, choose, dismiss or move away] Keyboard tasks: [reach, choose, leave, continue] Unresolved behavior: [describe what still needs a decision]

Worked example, assuming the header contains links to Home, Services, and Contact: record “Purpose: destinations” and “Chosen pattern: navigation list with ordinary links.” Then test each destination with a pointer and with a keyboard, and note any item that cannot be reached or activated as intended. If a panel opens, add its opening and leaving behavior to both test lists. If the purpose is instead a set of application commands, record why that interaction calls for the application-style pattern and test its required focus and arrow-key behavior. [S1] [S2]

A test plan is a way to find gaps, not proof that the finished site meets every accessibility requirement. Check the actual interface and implementation, and seek a qualified accessibility review if the pattern or results are unclear.