-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add section about compatibility with Accessibility 1.0 #2527
base: main
Are you sure you want to change the base?
Conversation
I would personally prefer to leave it to the maintenance group. Even if agreed, it unclear at this moment when an arratum to an idpf document could be added; there may be a number of temporary obstacles. This change should, logically, come after that erratum. |
The situation has changed since my comments of a month and the half ago; what we published was a new CR and adding this (editorial) change to the document before we go to PR sounds appropriate. |
The problem is getting an erratum for 1.0. We have a page for it at https://idpf.org/epub/a11y/errata/, but it'll take getting the old IDPF site updated, or getting a redirect on that URL to a new document that we host in W3C space. Do you think either of those are likely at this time? |
Oops, sorry... We always get back to the same issue: is there a way to change the idpf.org website in any way (I certainly do not have access to it). And I do not have the answer... Cc-ing to @swickr @vivienlacourba here. I believe at this moment only @vivienlacourba has real access to the IDPF site (I am not even sure where those files are, physically) and he probably has his hands super-full with the W3C transition issues... |
This pull request becomes valid assuming we agree to publish the erratum noted in issue #2526.
If we can vote on moving ahead with that erratum on this week's call, this pull request doesn't add any new normative requirements.
If it's too late to change the specification and vote on moving to PR in the same call, we can defer integrating this and leave it for the maintenance group. Getting the erratum agreed on is more important and it doesn't affect the transition of the specifications.