Put your mouse aside for a moment and try navigating the Internet. You'll quickly find that you can't control every Web site with the keyboard. Where you can, use the tab key to move through the Web site and see which element is selected. Any element that can be operated with the mouse should also work with a keyboard. Menus and navigation usually require extra attention. To make those as accessible as possible, we as developers use native HTML elements as much as possible, include clear focus styles and we pay attention to making sure the tab order is logical.
Building a page with descriptive HTML elements and proper hierarchy in header levels is crucial for assistive technologies such as screen readers. Use semantic elements only as intented: mark headings as <H1>, <H2> etc. Use <ul> for lists and only put main naviation blocks in <nav>. <span> en <div> elements have no structural or semantic roles to play. HTML5 landmarks such as <header>, <footer> and <main> then again give structure and added value to the page.
Each browser builds an accessibility tree for itself from the code. Supporting technologies retrieve it to pre-read and announce information. In the accessibility tree, each component has a role, a name, a state and properties. Semantic HTML elements fill out the accessibility tree, but as developers, we can add or adjust missing semantics with Accessible Rich Internet Applications attributes (ARIA). For example, we can assign a label to the navigation or provide the status of a button. ARIA attributes only belong on components with a semantic role. Wrong or redundant ARIA attributes do not help accessibility.