Skip to content
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

No information is available needs IDs and a review #538

Open
GeorgeKerscher opened this issue Dec 13, 2024 · 4 comments
Open

No information is available needs IDs and a review #538

GeorgeKerscher opened this issue Dec 13, 2024 · 4 comments

Comments

@GeorgeKerscher
Copy link
Collaborator

In Pr 535, I mention that the last statement in examples is "No information is available" and this needs to be reviewed. I wanted to capture this issue instead of having get lost when that PR is merged.

In many places there was a variable and a ID string that matched well. However, in other places the logic in the techniques do not lead to that statement; I would call this a fall through statement, i.e., the condition where everything fails because there is no metadata present.

There are also the markup of the ID that should be placed in the guidelines.

I think the guidelines should be updated after the techniques are revised.

@mattgarrish
Copy link
Member

The recent removal of the headings makes these fall-through statements confusing. There's now nothing in the techniques about how to add headings, presumably forcing implementers to read the json file to figure out what to do, although even that is not made clear.

But if the headings are now at the discretion of implementers, it means you could get multiple "no information available" statements with no context. It's also not clear how the statements would be modified depending on whether the implementer uses the predefined headings from the guidelines or whether they come up with some new heading group of their own.

@GeorgeKerscher
Copy link
Collaborator Author

If it were me designing a site, I would group as follows:

h1 Ways to read I or perhaps reading modes)
Then the results from visual adjustments, non-visual reading, and Audio books.

h2 conformance
with the results from conformance

H2 navigation
results from navigation

h2 Rich content (only if there is information)

H2 features
then the results from
hazards, additional information
H2 Additional information
I would put the accessibility summary here.

What this tells me is that perhaps our headings are slightly incorrect. Additional information should be the heading for accessibility summary, because the semantics have changed. The additional information should be more features.

@mattgarrish
Copy link
Member

But if we don't standardize the heading output, the display could be just about anything. I'm not sure how the algorithm works in that scenario to get the strings to display when the heading context is lost.

You also have to know that instructions are now in the json file instead of in the techniques document that's supposed to be describing the process of generating the output.

I've been thinking of this process as getting to a place where users would always receive the same information even if its styling was slightly different, sort of like a nutritional label on food. It seems like we're moving in the opposite direction if the structure of the information can't be guaranteed from implementation to implementation.

@GeorgeKerscher
Copy link
Collaborator Author

I agree that we should get to a consistent output like nutrition information.

Would we add headings back?
Would we assume that information about file format is present? I mean EPUB 2, 3, audio book, PDF?
I still feel that if it is an audio book that this fits with ways to read/reading mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants