Skip to content

Updates to nav processing#2479

Merged
mattgarrish merged 3 commits intomainfrom
fix/issue-2477
Nov 17, 2022
Merged

Updates to nav processing#2479
mattgarrish merged 3 commits intomainfrom
fix/issue-2477

Conversation

@mattgarrish
Copy link
Member

@mattgarrish mattgarrish commented Nov 11, 2022

This pull request fixes #2477 as follows:

  • adds a requirement that reading systems use the alternative text for non-text elements that are not supported in a non-html rendering of a nav component. Also adds precedence rule for alt over title and lets RS do what it wants when neither are specified.
  • adds a caution to the authoring spec that reading systems that build their own navigation widgets may not be able to retain element- and attribute-based rendering instructions, so authors need to be aware of possible usability issues
  • adds an image with alt text to the nav patterns example

I don't expect that requiring the use of the alt text will be controversial, as when it's not used you generally get a really bad user experience. Open to suggestions on the authoring caution, though. I don't want to tell people not to use html formatting, as it could be fine in a browser-based reading system, or when used in spine, so I tried to tie it into being a usability issue.

Reading Systems:


Preview | Diff

…ctions in nav elements;

add example of an image with alt text to the nav patterns example;
require that reading systems use the alternative text for non-text elements that they don't support
Copy link
Member

@iherman iherman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only worry is that, by introducing a new MUST statement in the RS spec, we must create a test asap (which is of course easy), but we will have to nudge implementers to run it. As we are in the danger not to find enough implementations implementing this MUST, it puts us into a strange spot. But we may have to do that anyway.

I have (again) some serious home networking issues, so I am not sure if I can create those tests easily now (although the tests are probably easy to do). Hopefully I will be able to do that by the middle of next week, unless someone beats me into it...

@wareid @dauwhe

@mattgarrish
Copy link
Member Author

I think I'd be fine with a "should" given the time constraints, but it's such a terrible user experience to have entries with no labels, or where you get the value of a src attribute. Unless you know of a reading system that will support images and multimedia and target only it, you're just asking for trouble to use the elements.

I'd probably favour banning embedded and interactive content, given there's no support for these anyway. That the fallback text also isn't supported only worsens the situation. There's just a risk that we could invalidate some content if we change the model, but in this case I'd have to think it'd be pretty small.

@mattgarrish
Copy link
Member Author

given there's no support for these anyway

Found one major reading system that displays images, at least, so leaving the content model alone is probably wisest.

@iherman
Copy link
Member

iherman commented Nov 14, 2022

given there's no support for these anyway

Found one major reading system that displays images, at least, so leaving the content model alone is probably wisest.

Great. Then my proposal is to merge the text as proposed, and I will come up with 2-3 tests for it.

@mattgarrish mattgarrish merged commit 95999e5 into main Nov 17, 2022
@mattgarrish mattgarrish deleted the fix/issue-2477 branch November 17, 2022 13:45
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

Successfully merging this pull request may close these issues.

Example of non-textual descendant concatenated label in nav elements

3 participants