Accessibility Statement
GPT LLM ORAGLE Ltd. Liability Co. is committed to making GPTpost usable by everyone, including people who use screen readers, keyboard-only navigation, magnification, speech input, or reduced-motion settings.
This statement says what we target, what we have actually done, and where we currently fall short. An accessibility statement that lists no gaps is not credible, so ours lists them.
Report a barrier to support@oraglegpt.org with "Accessibility" in the subject line.
1. Conformance target
| Item | Position |
|---|---|
| Standard targeted | Web Content Accessibility Guidelines (WCAG) 2.2 Level AA |
| Current conformance status | Partially conformant. Most of the Service meets Level AA. The exceptions are listed in section 5 |
| Also aligned with | EN 301 549, Section 508 of the US Rehabilitation Act, and the accessibility requirements of the European Accessibility Act |
| Scope of this statement | The public pages at oraglegpt.org, including all pages under /legal/, and the GPTpost web application |
"Partially conformant" means the Service conforms to most of the standard but not to all of it. We say so rather than claiming full conformance.
2. What we have done on these legal and public pages
Every page under oraglegpt.org/legal/ is built to be read by anyone, on any device, without JavaScript:
- Server-rendered HTML. The content is in the initial response. It does not depend on script execution, so screen readers, text browsers, and automated checkers all receive the full text.
- Skip link. A "Skip to main content" link is the first focusable element on every page.
- Landmarks. Each page uses
<header>,<nav>,<main>, and<footer>landmarks, with accessible names on the navigation regions. - Heading structure. Exactly one
<h1>per page, with<h2>and<h3>in order and no skipped levels, so heading navigation works. - Contrast. Body text and interface text meet or exceed the 4.5:1 ratio required at Level AA, in both the light and dark colour schemes.
- Respects your system theme through
prefers-color-scheme, and respectsprefers-reduced-motion. - Visible focus. Every interactive element has a clear, high-contrast focus indicator that is never removed.
- Responsive and reflowable. Content reflows to a single column at 320 CSS pixels without horizontal scrolling, and remains usable at 200 percent zoom.
- Tables have proper header cells and captions, and scroll horizontally inside their own container so the page itself never scrolls sideways.
- No colour-only meaning. Where colour conveys status, text or a symbol conveys it too.
- No time limits, no motion traps, no autoplay on these pages.
- Text resizing works to at least 200 percent without loss of content, since layout uses relative units.
3. What we have done in the application
- Keyboard operation for the primary flows: composing, scheduling, approving, and publishing.
- Form fields have programmatically associated labels, and errors are announced rather than shown only in colour.
- Dialogs trap focus while open and return focus to the trigger when closed.
- Media uploads support alternative text, and we prompt for it rather than letting it be silently omitted.
- The interface is usable at 200 percent zoom.
4. Assistive technology we test with
| Environment | Assistive technology |
|---|---|
| Windows | NVDA with Firefox and Chrome |
| macOS and iOS | VoiceOver with Safari |
| Android | TalkBack with Chrome |
| All | Keyboard-only navigation, 200 percent zoom, forced-colours mode, reduced-motion |
Testing combines automated checks in the release verification gate with manual keyboard and screen-reader passes on the primary flows.
5. Known limitations
We are honest about these because a user is better served by knowing a barrier exists than by discovering it mid-task.
| Area | Limitation | Workaround | Status |
|---|---|---|---|
| Analytics charts | Data visualisations convey trends visually, and no chart in this build renders an equivalent data table beside it. A screen-reader user gets the chart's label and the surrounding heading and summary text, but not the individual data points. This row previously claimed that every chart had a corresponding data table; it did not, and does not | Sign in. The signed-in analytics screen draws no chart at all: it lists the underlying metric observations as a real data table, with an export button that writes the same figures to CSV. Any report generated through the reports screen can be produced as CSV or HTML, both of which carry every figure as text | Per-chart data tables are not implemented. We would rather state that than describe a workaround a user would go looking for and not find |
| Calendar drag-and-drop | Rescheduling by dragging a post on the calendar is a pointer interaction | Every drag action has a keyboard-accessible equivalent in the post's edit screen, where the date and time can be typed | Keyboard drag alternatives are being added to the calendar itself |
| Rich text editor | The composer's formatting toolbar is operable by keyboard, but screen-reader announcement of applied formatting is not yet complete | Compose in plain text, or use the Markdown-style shortcuts | In progress |
| Media cropping | The image crop tool is a pointer-driven canvas | Upload pre-cropped media, or set crop values numerically | Numeric crop entry is available; full keyboard cropping is planned |
| Third-party content | Content written by someone other than you - an inbox message or a comment submitted to the ingest API, or a media asset uploaded by a colleague - carries whatever alternative text its author supplied, and we cannot add alternative text on their behalf. This build pulls no content from a social platform, so the only third-party content here is what a customer put there | Not applicable | Outside our control |
| PDF exports | Generated PDF reports are not yet fully tagged for accessibility | Export the same report as CSV or HTML, both of which are accessible | Planned |
6. Preparation of this statement
- This statement was prepared on 2026-08-04.
- It is based on a self-assessment carried out by the Company, combining automated testing with manual keyboard and screen-reader review.
- It has not been reviewed by an independent third-party auditor. We say so rather than implying external validation we do not have.
- It is reviewed whenever the interface changes materially, and at least once a year.
7. Feedback and how we respond
If you cannot use part of GPTpost, tell us. We treat accessibility reports as defects, not as feature requests.
Email support@oraglegpt.org with "Accessibility" in the subject line, and include:
- the page or screen where the problem occurs;
- what you were trying to do;
- your operating system, browser, and assistive technology, if you know them.
What you can expect:
| Step | Target |
|---|---|
| Acknowledgement | 2 business days |
| Assessment, with a plan or a workaround | 10 business days |
| Fix for a barrier that blocks a core task | Prioritised in the next release |
If you need information from a page in an alternative format, ask us and we will supply it.
8. Enforcement and escalation
If you are not satisfied with our response, escalate to legal@oraglegpt.org.
Depending on where you live, you may also be able to complain to a national enforcement body responsible for the European Accessibility Act, to an equality or disability rights body, or to the relevant authority under Section 508 or the Americans with Disabilities Act. You do not have to exhaust our process first.
9. Contact
| Topic | Address |
|---|---|
| Accessibility barriers, alternative formats | support@oraglegpt.org |
| Escalation | legal@oraglegpt.org |
GPT LLM ORAGLE Ltd. Liability Co.
30 N Gould St, Ste N
Sheridan, WY 82801
United States