Accessibility should be a core element at the planning stage of a development project and remain central throughout the software development life cycle. Evaluating for accessibility at the end of the project is a sure way to necessitate many further cycles of design and code edits, further increasing costs and delaying rollout.
The agile methodology lends itself very strongly to incorporating accessibility. If enough resources are provided to making a product accessible as it is created, then many last-minute development challenges can be avoided.
Accessibility is a responsibility for the whole development team. If they are not aware of its critical importance, then this lack of awareness is an obstacle that must be overcome. If the Project Manager understands the importance of accessibility, then she can leverage that across the entire team.
In Agile project backlog and in the Scrum planning sessions, accessibility considerations must be kept in mind. For instance, if a developer has a ticket to embed a video on a page, one must consider: Is there a transcript for the video? Does it have captions? When creating a form, are the fields clearly and accurately labeled? Are the form error procedures effective, understandable and usable by screen readers? Acceptance criteria can be written to expect these requirements to be met. Quality assurance staff should be able to identify where issues arise and fail tickets accordingly.
As features are built, they should be tested for accessibility. For UX/UI designers, there are many aspects of accessibility that should be incorporated into their work. Can parallax features be made accessible? Or, is there an alternative way of relaying the same information in a manner which is simpler and can perhaps delivers a better usability experience for all?
As the sprint process continues for a project, within a few iterations, it should become ingrained in the team that accessibility is expected and that work will be reviewed against WCAG 2.x guidelines. This mindset shift in developers, designers and QA staff will assist in creating a better product. Also, it should alleviate extra work at the end of the project or the sprint trying to remediate any number of accessibility failings.
The Agile software development value of “working software over comprehensive documentation” clearly supports accessibility. If a site is inaccessible, then simply put, you do not have working software!