Accessibility is not a layer you paint on after the structure is done. The same decisions that make a site findable, clear labels, predictable landmarks, a depth people can keep in working memory, headings that match the outline, are what make it usable with a screen reader, a keyboard, or a high zoom level. An IA that buries a critical task three ambiguous clicks deep fails a screen-reader user harder than a mouse user, because every wrong turn costs more to reverse.
Treat structure as an accessibility surface. Navigation should expose a consistent order and naming system so assistive tech can announce a stable map. Skip links and landmark regions only help if the underlying sections are real. Labels must be unique within a view; two "Learn more" links that go to different places are an IA failure as much as an a11y failure. Search is often the fastest path for people who cannot efficiently browse, which is why a broken zero-results page is an accessibility bug, not only a findability one.
If a structure only works when you can see the whole page at once, it is not finished. Accessible IA is the same IA, held to a harder test.
Rename the ambiguous Apply items and keep search consistently available. Ambiguous sibling labels and a search field that comes and goes are structure and wayfinding problems, exactly what assistive-tech users hit first. Contrast and shadows can help vision, but they do not fix a map that cannot be told apart by name. Stuffing more into "More" and papering over names with ARIA leave the underlying IA confusion in place.
Approving an IA first and "adding accessibility later" usually locks in depth, labeling, and navigation patterns that are expensive to unwind. The cheaper moment to ask "can this be operated without sight, and without a mouse?" is while the structure is still a draft.