hello@ediway.co.uk

hello@ediway.co.uk

ACCESSIBILITY STATEMENT

Designed for More People.Improved Through Testing, Feedback and Continued Review.

EdiWay is built for a wide education community: learners, parents and carers, teachers, school leaders, support staff and authorised professionals. Those users do not all interact with technology in the same way.

Some use keyboards instead of a mouse. Some use screen readers, magnification or speech tools. Some need clearer language, stronger visual structure or more predictable interfaces. Others may experience sensory, cognitive, learning, motor or communication differences that affect how they use digital services.

We aim to make EdiWay as accessible and usable as reasonably possible across its public website and platform experiences, while continuing to test, identify and improve areas that create barriers.

  • Inclusive by Design
  • WCAG-Informed
  • SEND-Aware
  • Continuously Reviewed
Explore Trust and Governance
Report an Accessibility Issue

OUR ACCESSIBILITY APPROACH

Accessibility Isa Product Responsibility.

Accessibility should not be something added after a feature has been built. EdiWay's approach is to consider accessibility through design, development, content, testing and release assurance.

That means considering more than whether a page looks clear on one screen. We consider how people navigate, understand information, complete forms, receive feedback, interact with controls, use different screen sizes and access important workflows through assistive technologies.

Accessibility also forms part of EdiWay's wider product-assurance model. Where a capability still requires accessibility verification, we should not present that capability as universally accessibility-assured until the required testing has been completed.

OUR TECHNICAL TARGET

Working TowardsWCAG 2.2 Level AA.

EdiWay uses the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as the primary technical accessibility target for web experiences. WCAG provides internationally recognised guidance for making web content more accessible to people with visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

Our accessibility work therefore considers areas including:

  • Keyboard operation and visible focus; semantic structure and screen-reader support; text resizing, zoom and responsive layouts; colour contrast and information that does not depend on colour alone; meaningful labels, instructions and error messages; appropriately sized and operable controls; understandable navigation and consistent interactions; accessible authentication and forms; alternatives for meaningful non-text content; accessible documents and generated content where supported.

Meeting individual accessibility criteria is not the same as proving complete site-wide conformance. EdiWay should only claim full WCAG 2.2 AA conformance when appropriate testing demonstrates that the relevant experience meets that standard in full.

CURRENT ACCESSIBILITY STATUS

Improvement Is Ongoing.We Do Not Treat Accessibility as Finished.

EdiWay is actively developed, and its platform contains a wide range of public pages, dashboards, forms, workflows, reports, and role-specific experiences.

Accessibility checks form part of product and release assurance, but not every workflow has necessarily completed the same level of accessibility testing at the same time.

For that reason, EdiWay does not currently make a blanket claim that every public page, authenticated workspace, generated document or advanced workflow is fully conformant with WCAG 2.2 AA unless that specific experience has been appropriately tested and assured.

Our objective is to continue moving platform experiences towards that standard and to address identified barriers as part of ongoing development.

KEYBOARD ACCESS

Important WorkShould Not Depend on a Mouse.

People may navigate EdiWay using a keyboard, switch device or other non-pointer input.

Interfaces should therefore support logical navigation through interactive elements, clear focus indication and controls that can be operated without requiring precise mouse movement.

Keyboard accessibility is particularly important for complex education workflows containing menus, forms, tabs, dialogs, tables and repeated actions.

New and updated experiences should be reviewed for keyboard operation as part of accessibility assurance.

SCREEN READERS AND STRUCTURE

Make the InterfaceUnderstandable Without Seeing Its Layout.

Visual design can show relationships through spacing, colour, size and position.

Assistive technology needs those relationships to exist in the underlying structure too.

EdiWay aims to use meaningful headings, labels, form relationships, landmarks, control names and status information so screen-reader users can understand and navigate an interface without relying on its visual appearance alone.

Where an icon or visual indicator communicates important information, an appropriate accessible alternative should also be available.

ZOOM, TEXT AND RESPONSIVE USE

Let UsersAdapt the Interface to Them.

People may enlarge text, zoom the page or use a smaller screen because of visual, motor or situational needs.

EdiWay interfaces are intended to work responsively across supported screen sizes and to remain usable when users increase text or browser zoom.

Layouts should avoid requiring users to read tiny fixed text or unnecessarily scroll in multiple directions simply to complete an ordinary workflow.

Responsive appearance alone does not prove accessibility, so these behaviours remain part of ongoing testing.

COLOUR AND VISUAL INFORMATION

Colour Can Support Meaning.It Should Not Carry Meaning Alone.

Education platforms often use colours for statuses, priorities, progress and alerts.

Where information is important, users should not have to distinguish colours alone to understand it.

EdiWay's design direction is therefore to combine appropriate colour contrast with text, labels, icons, patterns or other indicators where needed.

This is particularly important in areas such as attendance, reporting, SEND, safeguarding, actions and operational status.

FORMS AND ERRORS

Make It ClearWhat Needs to Happen Next.

Schools and families use EdiWay for information-heavy tasks.

A form that is technically available but difficult to understand can still create a significant barrier.

Forms should aim to provide clear labels, understandable instructions and useful validation.

When something goes wrong, the user should be helped to understand what needs attention rather than being expected to find an unexplained red field or interpret a technical error.

Where information is sensitive or consequential, accessibility must work alongside privacy, permissions and human review.

COGNITIVE AND LEARNING ACCESSIBILITY

Accessible MeansMore Than Screen-Reader Compatible.

EdiWay serves learners and adults with different cognitive, literacy, attention, processing and learning needs.

We therefore aim to make interfaces easier to understand through clearer language, predictable navigation, meaningful headings, manageable task sequences and reduced unnecessary complexity.

This is particularly relevant to learner-facing and family-facing experiences.

Where AI assistance is used to simplify or restructure information, the resulting content still requires appropriate human review and should not change the underlying meaning or professional authority of the source.

SEND-INCLUSIVE DESIGN

Understand Difference.Don't Assume One User Experience Fits Everyone.

EdiWay's broader learner model recognises that people may have different communication, sensory, learning and accessibility requirements.

Accessibility and SEND are related, but they are not identical.

A learner may need a specific educational adjustment that is different from a technical website-accessibility requirement.

Similarly, meeting a technical WCAG criterion does not guarantee that an experience works well for every learner with SEND.

EdiWay therefore treats technical accessibility, inclusive design and individual learner support as connected but distinct responsibilities.

LEARNER-FACING EXPERIENCES

Design for the Learner.Not Simply a Smaller Adult Dashboard.

Learner-facing interfaces should take account of age, comprehension, independence and accessibility.

The amount of information shown, the language used and the actions available may need to differ from staff interfaces.

For younger learners and learners with additional needs, unnecessary complexity can itself become a barrier.

EdiWay's direction is therefore to make learner experiences focused, understandable and appropriate to the task rather than exposing administrative complexity simply because the underlying platform can support it.

PARENTS AND CARERS

Family AccessNeeds to Work for Different Users Too.

Parents and carers may themselves have accessibility requirements.

Family-facing services should therefore be designed with the same accessibility considerations as staff and learner experiences.

Important school communication, forms, consent requests, payments, learning information and support processes should not depend on a parent or carer being able to use one particular input method or interpret a complex administrative interface.

Accessibility forms part of meaningful family participation.

AUTHORISED PROFESSIONALS AND STAFF

Accessible WorkflowsSupport Better Professional Practice.

Teachers, SENCOs, DSLs, administrators and authorised professionals may spend significant time using education systems.

Barriers that make routine actions slower or harder can increase workload and create avoidable mistakes.

Accessible interaction therefore supports not only inclusion but also clearer operational practice.

Role-specific workspaces should aim to surface the information and actions needed for the task without forcing users through unnecessary interface complexity.

DOCUMENTS AND DOWNLOADS

Accessibility Should ContinueBeyond the Web Page.

EdiWay may present or generate information in downloadable formats.

The accessibility of a generated document can depend on its template, structure, content, data and final review.

Document-generation capability should therefore not be assumed to guarantee that every resulting PDF, Word file or export is automatically accessible in every circumstance.

Where a document is important and an accessible version is needed, users should be able to raise that requirement through the appropriate support route.

Schools and other organisations uploading their own documents also remain responsible for considering the accessibility of the content they provide.

SCHOOL AND USER-CREATED CONTENT

Accessible Platform ToolsStill Need Accessible Content.

EdiWay can provide an accessible framework while schools, staff and other authorised users contribute their own resources, documents, links, images and communications.

Content creators should consider accessibility when publishing through the platform.

That can mean using meaningful headings, descriptive link text, appropriate image descriptions, understandable language and accessible document formats.

EdiWay aims to make accessible publishing easier, but user-created content may vary according to its source.

THIRD-PARTY SERVICES AND CONTENT

Some JourneysMay Cross an External Boundary.

Certain EdiWay workflows may connect to third-party services or content.

Accessibility of an external website, payment service, AI provider, embedded resource or third-party document may be outside EdiWay's direct control.

We aim to consider accessibility when selecting and integrating external services, but those providers may operate under their own accessibility standards and statements.

Where an external dependency creates a material accessibility barrier, we want users to report it so the impact can be understood.

ACCESSIBLE COMMUNICATION

Clear InformationIs Part of Accessibility.

Accessibility is affected by how information is written as well as how the interface is coded.

EdiWay encourages content that is structured, purposeful and understandable.

Important communication should avoid unnecessary complexity where simpler language communicates the same meaning.

However, simplifying language should not remove important safeguarding, legal, SEND, medical or professional meaning.

The aim is clarity without loss of accuracy.

ACCESSIBILITY AND AI

AI Can Help With Presentation.It Does Not Prove Accessibility.

Where enabled, EdiWay AI may help authorised users restructure or simplify draft content.

That can be useful for preparing clearer communication or learning material.

But AI-generated content can still contain accessibility problems.

Human review remains necessary to check areas such as language, structure, alternative text, audience suitability, accuracy and whether the output works for the intended user.

AI does not certify content as accessible.

Read About AI Governance
Explore EdiWay AI

TESTING ACCESSIBILITY

Automated Checks Help.Human Testing Still Matters.

Accessibility cannot be established through one automated score.

Automated tools can detect some problems, but they cannot reliably determine whether every interaction is understandable or usable.

EdiWay's assurance approach can therefore include appropriate automated checks alongside manual review of areas such as keyboard use, focus, forms, responsive behaviour, screen-reader interpretation and complex workflows.

Representative testing should also reflect the different types of experiences across the platform rather than assuming one successful page proves accessibility everywhere.

BUILD, TEST, IMPROVE

Accessibility Isa Continuing Product Cycle.

For new and changing areas of EdiWay, the intended approach is:

  • Design with accessibility in mind.
  • Build using appropriate semantic and interaction patterns.
  • Test representative experiences and failure states.
  • Review identified barriers.
  • Prioritise issues according to user impact.
  • Fix problems through product development.
  • Retest important changes.
  • Listen to people using the platform in real conditions.

Accessibility assurance should develop alongside the product rather than becoming a one-off exercise before launch.

REPORT AN ACCESSIBILITY PROBLEM

Tell UsWhere EdiWay Is Creating a Barrier.

We want to know when someone cannot access information, understand an interface or complete an important task because of an accessibility problem.

When reporting an accessibility issue, it helps to tell us which page or part of EdiWay you were using, what you were trying to do, what happened, and any assistive technology or device information you are comfortable sharing.

You can raise accessibility issues through the EdiWay support.

We can then investigate the problem, consider an appropriate workaround where available and use the report to inform future accessibility improvements.

Contact EdiWay Support

ALTERNATIVE ACCESS

When Something Is Not Accessible,
Ask for Another Route.

Where EdiWay-controlled information cannot currently be accessed in a usable format, contact us through the support route and explain what you need.

Where reasonably possible, we will work to identify an alternative way to provide the relevant information or support access to the affected workflow.

Where the inaccessible content belongs to a school or another organisation rather than EdiWay, that organisation may need to provide the appropriate alternative format.

COMPLIANCE AND PUBLIC-SECTOR USE

Accessibility Standards Matter.Claims Still Need Evidence.

WCAG 2.2 AA is EdiWay's technical accessibility target. Public-sector organisations using digital services may also have their own duties under applicable accessibility and equality requirements.

  • EdiWay's role is to provide and improve accessible platform capability.
  • Each organisation remains responsible for understanding the obligations that apply to the digital services and content it provides.
  • EdiWay should not claim statutory accessibility compliance, certification or endorsement simply because accessibility has been considered during development.

PREPARATION AND REVIEW OF THIS STATEMENT

Keep the Statementas Current as the Platform.

This statement reflects EdiWay's current accessibility approach and product-assurance position.

It should be reviewed when substantial changes are made to the platform, when material accessibility testing produces new findings, and as part of a regular accessibility review cycle.

Where a formal accessibility audit is completed, this page should be updated to state clearly:

the scope tested, the date tested, the standard used, the testing method, the resulting compliance status, known non-accessible content and planned remediation.

Until that evidence is available, EdiWay should not describe the entire platform as fully WCAG 2.2 AA compliant.

FREQUENTLY ASKED QUESTIONS

Is EdiWay fully WCAG 2.2 AA compliant?

WCAG 2.2 AA is EdiWay’s accessibility target.

EdiWay should only describe a website or platform experience as fully conformant when appropriate testing demonstrates that all relevant Level A and AA requirements have been met for the stated scope.

Does EdiWay support keyboard users?

Keyboard operation is an important part of EdiWay’s accessibility direction and testing approach.

Individual workflows remain subject to ongoing accessibility assurance.

Does EdiWay work with screen readers?

EdiWay aims to provide semantic structure, labels and navigable interfaces suitable for assistive technologies.

Compatibility needs to be verified through appropriate testing across relevant experiences.

Can users zoom or enlarge content?

EdiWay’s responsive design direction aims to support browser zoom, text enlargement and different viewport sizes without making ordinary workflows unusable.

Is accessibility only relevant to learners with SEND?

No.

Accessibility can affect learners, parents and carers, staff and authorised professionals.

SEND support and technical accessibility overlap in some areas but remain distinct concepts.

Are EdiWay-generated documents automatically accessible?

Not necessarily.

Accessibility can depend on the document type, template, data and content, so generated outputs may require additional review.

What about documents uploaded by schools?

Schools and other content creators remain responsible for considering the accessibility of resources and documents they publish.

Can AI make content accessible automatically?

No.

AI may assist with draft wording or structure where enabled, but accessibility still requires human review and appropriate testing.

How can I report an accessibility problem?

Use the EdiWay support or contact route and describe the page, task and barrier you experienced.

Can I request information in another format?

Where EdiWay controls the relevant content, contact support and explain the alternative format or access need.

Where another organisation owns the content, that organisation may need to respond to the request.

CONNECTED GOVERNANCE

Accessibility Is Partof the Wider Assurance Model.

Trust and Governance

See how accessibility fits alongside privacy, security, permissions and accountability.

Explore Trust and Governance

Privacy and Data Protection

Understand how accessibility works alongside appropriate information use and sensitive-data boundaries.

Explore Privacy and Data Protection

Implementation, Migration and Product Assurance

Understand how accessibility checks fit into broader release and deployment assurance.

Explore Product Assurance

Sensory, SEND and Wellbeing Support

Explore how individual learner needs can be supported separately from technical platform accessibility.

Explore SEND and Wellbeing Support

AI Governance

See how AI-generated and learner-facing experiences remain subject to human and accessibility considerations.

Explore AI Governance

ACCESSIBILITY STATEMENT

Make the Platform Workfor More of the People It Serves.

  • Design for different ways of navigating.
  • Use clear structure.
  • Make important controls operable.
  • Avoid relying on colour alone.
  • Consider cognitive and learning accessibility.
  • Support different devices and assistive technologies.
  • Test real workflows.
  • Listen when users find barriers.
  • And keep improving as the platform grows.

Accessibility is not a feature to switch on.It is part of building education technology responsibly.

Report an Accessibility Issue
Explore Trust and Governance
Read the EdiWay White Paper
Shopping Basket