Welcome Page: What's This and How Do I Use It?

Extended Description

As a FedRAMP reviewer, to best understand my initial or ongoing use of the prototype UI, I would like to have level-setting information about what this is, why am I using this new tooling so different from my current tools and workflows, and what are the expectations of how I use it?

Preconditions

Acceptance Critera

[x] A welcome page with brief explanation answering the above.
[x] A banner or header of some kind (I do not want to be prescriptive, examples) that links to that page so a first-time or repeat reviewer test user will know what this is about
[ ] A screenshot to present the before and after once this is implemented

Story Tasks

[x] Work with Robin on best fit and slim information for that page
[x] UI implementation

Definition of Done

[x] Acceptance criteria met - Each user story should meet the acceptance criteria in the description
[ ] Unit test coverage of our code > 90% (from QASP) this may be fuzzy and hard to prove
[ ] Code quality checks passed - Enable html tidy with XML code standards as part of the build (from QASP)
[x] Accessibility: (from QASP) as we create guidance or documentation and reports (semantic tagging including aria tags): demonstrate with 0 errors reported for WCAG 2.1 AA standards using an automated scanner and 0 errors reported in manual testing
[x] Code reviewed - Code reviewed by at least one other team members (or developed by a pair)
[x] Source code merged - Code that’s demoed must be in source control and merged
[x] Code must successfully build and deploy into staging environment (from QASP): this may evolve from xslt sh pipline into something more
[x] Security reviewed and reported - Conduct vulnerability and compliance scanning. threat modeling?
[x] Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities (from QASP)
[ ] Usability tests passed - Each user story should be easy to use by target users (development community? FedRAMP FART team)
[ ] Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end). (from QASP)
[x] Code refactored for clarity - Code must be clean, self-documenting
[x] No local design debt
[ ] Load/performance tests passed - test data needed - saxon instrumentation
[ ] Documentation generated - update readme or contributing markdown as necessary.
[ ] Architectural Decision Record completed as necessary for significant design choices

18F / fedramp-automation

Welcome Page: What's This and How Do I Use It? #171