WebStorm Emmet integration and screen-reader-friendly markup: controlling expansion output for accessibility

I'm standardizing a team workflow around WebStorm's Emmet integration for rapid HTML authoring, and the goal is to ensure that expanded abbreviations consistently produce accessibility-friendly markup (landmark elements, lang attributes, alt placeholders) without manual cleanup afterward.

The documented pieces seem to support this: Emmet expands abbreviations via the Tab key in a keyboard-only flow, and Settings > Editor > Emmet allows custom abbreviations and snippets. What is less clear is how far that customization goes when the requirement is not just speed but enforced structure — for example, whether a custom snippet can reliably override a built-in abbreviation like ! so every new document skeleton includes our accessibility baseline, and whether per-file-type context (HTML vs XHTML) changes which snippet wins.

Assume a recent WebStorm release; I understand Emmet defaults can differ across major versions, so answers should note version sensitivity.

1. Can a custom Emmet snippet fully replace a built-in abbreviation's output, or does the built-in take precedence in some contexts?
2. Is there a supported way to scope custom Emmet snippets per project rather than per IDE installation?
3. When a custom abbreviation conflicts with another plugin or shortcut, what determines the expansion outcome?