Accessibility issues 1/2

Here is a collection of issues found from internal accessibility testing. Please split as you like.

- [ ] can tables be sorted?
- [ ] captions and possibly summaries for tables
- [ ] use black text on white background even for error and success messages (for better contrast). Use e.g. a coloured border instead of a solid box.
- [ ] After navigation to application, the focus is not in a useful place i.e. screen reader does not immediately read anything useful about where it just went.
- [ ] Screen reader reads the "please wait" when navigating although the page load is almost instantaneous.
- [ ] After sending application, consider placing focus somewhere more useful because it's difficult to do anything useful e.g. co to the beginning of the page or catalogue.
- [ ] Project name field in an example application reads "Project name project name star star edit required invalid entry has autocomplete" which is completely wasteful and almost unusable
- [ ] Navigating to terms of use does not say that we are in the terms of use block. It just starts reading about licenses that are links.
- [ ] More info links should have a label that says show more info about what.
- [ ] Show more link should have a label that says show more of what.
- [ ] Consider summarizing the State block while application still in draft phase or for applicants.
- [ ] Shopping cart apply link should say something useful i.e. refer to the resources that are going to be applied.
- [ ] Consider moving focus to cart after adding to the cart or some ability to navigate to it easily

Split this collection into focused accessibility issues before starting. Begin by reproducing the navigation, form, table, terms-of-use, and shopping-cart behavior with a screen reader, then identify the affected UI entry points. Each resulting issue should define one change, its expected focus or accessible label, and a verification step.

Written by the indexing model from the issue text.