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

Remove redundant <dl> wrapper for the attribute table + prose block of each element #113

Open
AmeliaBR opened this issue Apr 20, 2016 · 3 comments

Comments

@AmeliaBR
Copy link
Contributor

A list with one entry is just confusing for screen reader users, especially when the "term" is a table containing <dfn> elements. The list structure is not visible at all for other users.

@AmeliaBR
Copy link
Contributor Author

As I noted in #219, some chapters don't use this structure.

I think I prefer the format that most elements in the paint server chapter use: a definition list, with the name of the attribute as the <dt>, then the <dd> contains:

  • a max one-line description
  • a box with with the value syntax, initial value, and animatable status,
  • keyword value descriptions as a nested definitions list
  • the prose description.

If we want to keep the attribute name inside the blue boxes, then we shouldn't use a definition list format: a table doesn't make sense as a definition term.

@boggydigital boggydigital removed this from the SVG Core clean-up milestone Jun 11, 2018
@boggydigital boggydigital added this to the SVG 2.1 Working Draft milestone Jun 11, 2018
@dirkschulze
Copy link
Contributor

@AmeliaBR I suppose you mean a template like the one used for markerUnits?

From accessibility point of view this should be fine though on a sequential reading one hears all headers first followed by the individual rows with values like attr name, value type and so on. IMO could be better eventhough a11y software does allow navigation in tables.

startOffset probably is an example of "blue boxes". This has nested <dl>'s. @AmeliaBR is it that what you did not like or feel is not as accessible as the first example?

Note that the 2nd example is very common in CSS specs. It might even be the only pattern used by CSS specs and seems to be more accessible for sequential only reading. Would you disagree?

@svgeesus
Copy link
Contributor

svgeesus commented Jan 7, 2019

If the nested dl formatting is sufficiently accessible and also is what bikeshed generates, we should use that for SVG vs. CSS spec consistency. If it is not, then it needs discussion on the bikeshed repo, and if there is agreement bikeshed should get a PR for the change and we should also change to use that new formatting (again for SVG vs. CSS spec consistency).

If agreement is not reached fairly rapidly, this should be punted to the 2.1 milestone.

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

No branches or pull requests

6 participants