[Accessibility][Keyboard support] Add access keys & arrow keys docs and add clarify guidance

[citelao]

Today, our Keyboard support section does not include information about access keys or arrow keys, and doesn't have much documentation about default behavior or reference documents. This change adds guidance for access keys, arrow keys, and more, and documents the expected and default behavior for many of them.

Fixes #1229
Fixes #1225
Fixes #1226

Description

• Tab order
  • Added example of default behavior.
  • Clarified guidance & added documentation links.
  • Updated manual tab order example to differ from default behavior.
• Arrow keys
  • Added arrow keys section, with default example and custom example using XYFocusKeyboardNavigation.
  • Documented common expectations for arrow keys, like Home/End, PgUp/PgDn, and PosInSet/SizeOfSet.
• Accelerators
  • Demonstrate the default tooltip for keyboard accelerators.
  • Add an example with a custom tooltip.
• Access keys
  • Added an example of access keys, plus documentation.
• Landmarks & headings
  • Moved to Screen reader section, since it has no effect on Keyboard.
  • Added references for understanding headings & landmarks.
  • Added example with custom landmarks.
  • Documented "Narrator contexts", or how Narrator will read controls within named accessible groups.

Motivation and Context

This addresses documentation gaps in our keyboard examples. Hopefully it will lead folks to design more keyboard-accessible UI.

How Has This Been Tested?

Deployed locally.

• Narrator correctly narrates new content.
• Keyboard examples work as described.
• Links work
• Why aren't accelerator keys correctly setting the UIA AcceleratorKey property?

Screenshots (if appropriate):

Keyboard page

Screen reader page

Types of changes

• New feature (non-breaking change which adds functionality)

[citelao]

We should probably add examples of access keys to the menubar pages!

[marcelwgn]

Did you mean to include the # inside the displayed text of the link? Maybe we use - instead if we want to indicate that we are only linking to sections of the same page?

[citelao]

I did deliberately chooose # as the separator. It's a bit dev-y, but my reasoning was that # represents an anchor link---it's the literal character used to denote anchors in a URL. I worried - would be too ambiguous (is this a subpage of a section? A long title? etc).

I'm open to changing it, though, if it's confusing.

[marcelwgn]

The only thing I'm afraid is people thinking this is by mistake though I think this is a risk we can take here. After all, our audience is mostly devs.

[marcelwgn]

I was thinking having it be present in the XAML sample code would be fine but I guess having it twice doesn't hurt and is also closer to reality when reading the sample code in app.

[marcelwgn]

PR looks good to me, thank you so much for working on all of this @citelao!

[marcelwgn]

@karkarl If you wanna take a look, otherwise I would merge this