Accessibility statement

PSX RiPPER is a free, open-source hobby project by Björn Wiberg. This statement follows the structure of the EU model accessibility statement (Commission Implementing Decision (EU) 2018/1523), adapted to a private project.

What this statement covers

This statement covers this website, psxripper.bjrn.nu: the home page, the five docs pages (user guide, configuration, MCP, FAQ, how it works), the changelog, the glossary, this page and the “not found” page.

It does not cover:

• The PS3 app itself. It runs on a games console, on a TV, and is used with the console’s pad; its screen is drawn by the app, not by a web browser, so the web guidelines below do not apply to it, and it has not been assessed against the software clauses of EN 301 549. The app’s remote view and its MCP server let you use it from a phone, a computer or an agent instead of the pad.
• Other websites this site links to, such as GitHub and redump.org.

Compliance status

This website is partially compliant with WCAG 2.2 (opens in a new tab) level AAA, because of the exceptions listed under Content that is not accessible.

It is partially compliant with EN 301 549 V3.2.1. Clause 9 (web content, which equals WCAG 2.1 level AA) is met on every page that was checked; the “partially” comes from clause 12 (documentation and support), see below.

What works

• Every page has a header, a site navigation, a main area and a footer, one main heading, and headings in order. A “Skip to content” link is the first thing the Tab key reaches.
• Every link and control can be reached and used with a keyboard, in reading order, with no trap. Code examples and tables that scroll sideways can be focused and scrolled with the arrow keys.
• The focused element always has a 3 px ring, drawn just outside it: amber on the page’s navy (at least 8.4:1), white around the lime download button (at least 3.9:1 against its glow).
• Text has a contrast of at least 7:1 against its background, including the lightest part of the page’s gradient. Button borders, the pad-button symbols and the focus ring have at least 3:1.
• Links, buttons and tabs that are not part of a sentence are at least 44 by 44 CSS pixels, except the “On this page” lists (see below).
• The pages work at a width of 320 CSS pixels (400 % zoom) without sideways scrolling, and with larger line, letter, word and paragraph spacing. Nothing on the site moves or flashes.
• Text reflows: when the window is made narrower or the page is zoomed, lines get shorter and nothing has to be scrolled sideways (WCAG 1.4.8, met through reflow, technique G204). At full width a line of running text holds up to about 100 characters, with a line height of 1.6.
• The header, with the tabs, the search and the GitHub link, stays at the top of the window while the page scrolls, where the window is at least 30rem (480 CSS pixels) high. It never covers the element that has keyboard focus or a heading reached by a link (WCAG 2.4.11 and 2.4.12). In a lower window it scrolls away with the page.
• Where the tabs do not fit on one row, they fold into a Menu button. It is a real button that says whether the menu is open, the menu holds the same links with the current page marked, and Escape closes it and puts focus back on the button. Without JavaScript all the tabs are shown instead.
• Docs pages, the changelog and this page have an “On this page” list of their sections: a column beside the text on a wide screen, which marks the section you are reading (for screen readers too), and a list under the summary on a narrow one.
• Search: on a wide screen the header has a search field. Moving to it with Tab only puts focus there; typing in it, pressing the down arrow or Enter, clicking it, or pressing “/” or “s” anywhere outside a text field opens the results in a dialog, with what you typed. Shift+Tab from the dialog’s field closes it and goes back to the tabs. On a narrower screen a Search button opens it. The field keeps focus while the arrow keys move through the results, which are grouped by page with passages of each match; Enter opens a result. Escape or the Close button closes the dialog and keeps your search, which the header then shows; the clear button empties it. The number of matches is announced to screen readers. While the dialog is open the page behind it cannot be reached or scrolled. Matches are marked like a highlighter, dark text in an amber box, not only by colour, and never underlined, so they cannot be taken for the result links, which are underlined. Search runs entirely in your browser with lunr, a search library served from this site: what you type is not sent anywhere, and no third party is involved.
• The current page is marked in the navigation, for screen readers too, and by a bold label and a white bar, not only by colour.
• The pad buttons in the text (the cross, circle, triangle and square symbols) are read out as “cross”, “circle” and so on. Decorative images are hidden from screen readers, and every screenshot has a text alternative that says what it shows.
• Links say where they go; links that open a new tab say so, for screen readers as well. The GitHub icon link is named “Source on GitHub”.
• Every page says in plain words, at the top, what it is about. Technical words and abbreviations (such as EDC/ECC, MCP, CFW, SBI, LibCrypt, MD5 and Redump) link to the glossary the first time they are used on a page.
• The language of the pages is set to English, and the few Swedish words in the text are marked as Swedish.

Content that is not accessible

These parts of the site do not meet WCAG 2.2 level AAA, or meet it only through an exception in the guidelines:

• The screenshots. They are pictures of the app’s own screen, so the text in them is an image, in English or Swedish, in the app’s colours. Some of that text is smaller and dimmer than 7:1, and it cannot be resized, recoloured or read out (WCAG 1.4.6 and 1.4.9). Showing the real screen is the point of a screenshot, so it is not replaced by text. Alternative: each screenshot has a text alternative and a caption, and the user guide describes every screen in text.
• Colours and layout cannot be chosen on the site (WCAG 1.4.8). The site has one dark colour scheme and no setting of its own for colours or text width; the text width requirement is met through reflow (see above). Alternative: the site uses no fixed colours that block your browser’s or system’s own colour, contrast and reading-view settings. The forced-colours (high contrast) modes of Windows and other systems have not been tested.
• Search needs JavaScript. Without it, the Search button is not shown. Alternative: every page is reachable from the tabs, and each page’s sections from its “On this page” list.
• The search dialog is the browser’s own modal dialog. Tab moves between the field, the clear button, the “more on this page” buttons and the Close button; after the last of them some browsers move focus to their own address bar before coming back. The page behind the dialog cannot be reached while it is open.
• Reading level (WCAG 3.1.5). The docs pages, most of all “How it works”, MCP and Configuration, explain technical things and need more than a lower-secondary reading level. Alternative: a plain-language summary at the top of every page, and the glossary.
• The changelog is written from the project’s commit messages. Its entries are short and technical, and its links are version numbers, issue numbers and commit codes. Alternative: each of those links has a hidden description for screen readers (for example “commit fb3249b”), and the release notes on GitHub hold the same information.
• Code examples show the app’s real output, which in a few places holds Swedish text (for example a Swedish label in a JSON reply). It is not marked as Swedish, because it is data, not prose.
• Links in sentences are as large as the text around them, not 44 by 44 pixels. WCAG allows this (2.5.5, inline exception).
• The “On this page” lists are compact: each link is 32 pixels high. That meets the 24 pixel minimum of WCAG 2.5.8 (level AA), but not the 44 pixels of 2.5.5 (level AAA). Alternative: every entry is also a heading on the page, so you can reach it with a screen reader’s heading navigation, or by scrolling.

Against EN 301 549 V3.2.1, clause 12:

• 12.1.2 (the documentation is accessible): met. The docs are these web pages, checked as above.
• 12.2.2 to 12.2.4 (support): met as far as a hobby project has support. You can ask for help or report a problem through GitHub issues, which needs a GitHub account, or by e-mail, which does not. Both are linked in the footer of every page.
• 12.1.1 (the documentation lists the accessibility features): partially met. This page lists the website’s accessibility features. The app’s documentation does not yet have a section on the app’s own accessibility features (for example the remote view and MCP as other ways to control it), because the app was not assessed.

How this statement was prepared

This statement was prepared on 8 November 2026, by a self-assessment of every page listed under What this statement covers:

• the automated checker axe-core 4.10 (all WCAG 2.0, 2.1 and 2.2 A, AA and AAA rules, and its best practices) in Google Chrome, at 1280 and 320 CSS pixels wide: no violations;
• a script that computes the contrast of every text, border and focus colour from the style sheet, against both ends of the background gradient, and a second one that checks the computed colours of every piece of text on every page;
• a script that moves through every page with the Tab key and checks the skip link, the order, traps, the focus ring and target sizes, and checks 320 pixel width, text spacing and line length;
• a script that moves forwards and backwards through every page at 1280, 768 and 375 pixels wide and checks that the sticky header never covers the focused element, and one that drives the Menu button and the search dialog with the keyboard (the arrow keys, Enter, Escape, Tab, “more on this page”) at 1280, 768, 375 and 320 pixels, with axe run while each is open;
• a review of the page structure, headings, names, text alternatives and language by hand.

The site has not been tested by people with disabilities, or by hand with a screen reader such as VoiceOver or NVDA. Line length was measured in the Verdana font, which is used where DejaVu Sans is not installed.

Feedback and contact

If something on this site does not work for you, or you need a page in another form, tell us:

• open an issue on GitHub (opens in a new tab) (needs a GitHub account), or
• write to b@bjrn.nu.

Enforcement procedure

PSX RiPPER is a private hobby project. It is not a public sector body, so the EU Web Accessibility Directive does not apply to it and there is no public enforcement body to turn to. Problems are fixed through the contacts above.