General Software Accessibility Remarks
======================================
* Main application navigation is fully keyboard accessible.
* Section-level controls are standard buttons or links, controllable via the keyboard.
* Application alerts and notices are focused by default and accessible via the keyboard.
* In sections where control order is unpredictable, the tabindex attribute is set to allow fine control over focused order.
* In complex controls, we define specific ARIA roles, concepts and/or properties to further enhance accessibility.
* Every possible effort is made to ensure the default browser navigation (Back, Forward, Refresh buttons) is predictable and usable.
* Link styles are altered for aesthetic purposes, but still retain expected defaults (underlined, contrasting color from body copy).
* An appropriate lang attribute is implemented for the application's markup.
* A HTML5 DTD is implemented allowing additional browser-specific accessibility features to become enabled automatically.
* Form elements and links are highlighted as focus is sent from one element to another.
* Custom UI components such as tabs provide focus to selected tabs as that focus changes.
* When pragmatically controlling a UI, we ensure focus is properly set to the intended elements.
* Most UI controls are browser-default links or buttons which provide purpose and state by default.
* Where graphical controls are required, a text equivalent is provided via the element’s alt attribute.
* Where custom controls are required, the controls are decorated according to the WAI-ARIA specification.
* All graphical elements which require a meaningful textual equivalent, such as loading indicators, alert indicators, and other iconography, are used in a predictable way across the entire application.
* Text equivalent content for images and icons is never changed pragmatically in the application.
* All textual information is provided to assistive technologies via the browser.
* We make no OS-level API calls.
* The application has no control over color or contrast settings.  All contrast and color settings are respected by the browser.
* There is no application setting for a user to change color schemes or contrast levels.
* There are no content animations used anywhere in the application.
* Occasionally, a loading animation is displayed to indicate a remote request or a possible long-running process; a text equivalent is set via the image’s alt attribute.
* Required fields in forms use both a highlight color as well as the ubiquitous asterisk (*).
* Fields with errors are highlighted but always provide descriptive error messages as LABEL elements, linked to the exact field which they describe.
* Data grids which support selectable rows properly trigger the focus() event to make AT aware of the change.
* There are no settings which permit a user to adjust color or contrast settings.
* There are no occurrences of flashing elements or blinking text.
* Browsers provide the default access to form field content.
* LABEL elements are used to establish an explicit link between text labels, error messages, and helpful hints to the elements which they describe.
* Where appropriate, instructive text is given for how to properly fill out the form.

Web Application Accessibility Remarks
=====================================
* All IMG elements include alt attributes.
* No Flash or CANVAS technologies are implemented.
* No video or presentations are implemented.
* Color coded content is used only to supplement existing textual content.
* Content is discernable from decoration in high-contrast, low color, or "no-style" settings
* Content is placed in a properly ordered heading (H1..H6) hierarchy, which can be used as a navigation device for screen readers and other AT. 
* Content is always coded in reading order as opposed to display order.
* No image maps are used.
* Data tables make use of proper table markup via THEAD, TH elements, apart from those in TBODY.
* All tables make use of COLGROUP, COL elements as well as headers attributes on data cells.
* No FRAME or IFRAME elements are used for content.
* In places where content is "embedded", it is placed inline in natural reading order and marked up with an ARTICLE element.
* Neither the screen nor any elements flash or flicker.
* All content on application pages is accessible without the use of alternate text-only pages.
* Dynamically generated content is primarily textual in nature, and made available to AT.
* Rollover effects are provided entirely via CSS and not scripted.
* There are no features that require the use of a Java applet or proprietary plugin.
* PDF content is generated by the application, but is offered as a supplemental document to accessible content offered within the application.
* See Remarks and Explanations for §1194.21(l)
* The very first piece of content in the BODY is a Skip to Main Content link.
* Where possible, markup is written in reading order so that the screen's primary content is as close to the beginning of the document as possible.
* Inactivity timer indicates a user has 60 seconds to extend session before being automatically logged out.

Functional Performance Accessibility
====================================
* All information content provided in MPower is available to be read aloud by a screen reader. 
* All browsers in our support grid implement full-page zoom, not text resizing.
* There is no auditory content within the MPower application.
* There is no auditory content within the MPower application.
* There is no feature that requires user speech.
* All actions required to provide input or to interact with content may be done with basic computer hardware.
* All components of the application are fully available to be interacted with by keyboard or similar hardware. 

Documentation and Support Accessibility
=======================================
* Documentation is available in the PDF format
* A General Accessibility Statement is universally available in the footer of the MPower application.