Should the Accessibility mixin support <br/> as a formatting tag

[zepumph]

Currently the mixin supports "formatting" tags that can be added to strings and rendered as html, but there is only a white list supported to prevent xss.

Questions

1. Do we want to support br tags so that individual p tags like the accessibleDescription can be more complex and powerful.
2. How does AT handle br tags? We should do a jsfiddle to experiment with them inside tags that support textContent like p and headers(?).

[zepumph]

Tagging @terracoda in case she has insight into br behavior with AT, and if this is a good improvement.

[terracoda]

@zepumph, in general in front-end development I would lean towards avoiding the use of br tags, but I can look into why more carefully.

[terracoda]

@zepumph, can you explain why you think br tags would make an accessibleDescription more complex or powerful?

br are not navigable like p tags or headings. The only thing a br tag seems to do is create a newline which interrupts a user who is reading with the virtual cursor. A closing block-level tag does the same thing.

For robust accessible descriptions, I think it is best to stick to html elements that provide semantic information about what the description: I am text in a paragraph, heading, list item, label, etc. I don't see a big need for br tags.

[terracoda]

Here's an interesting email discussion about carriage returns and screen readers announcing a new line.
One of the comments:

You can get a screen reader to announce a blank line if you have an empty block element (like the paragraph element) or a br element or a series of blank lines in a pre element.

[terracoda]

I'm not against supporting HTML tags, I just do not see any use for the br tag in the PDOM.

[zepumph]

@terracoda thank you for the info. I will inform you how this came up in discussion with @jessegreenberg and myself, and we will proceed from there as to if this is a worth while path to go down.

The current implementation of a11y descriptions onto a Node is currently very flushed out. There is quite a bit of flexibility as to what you can get that Node to look like in html. Most of these are straight forward, but I want to make sure I'm not confusing, so bare with me. A simple example:

A Node that is a p tag that holds a string that is the tag's text content.:
new Node( { tagName: 'p', accessibleLabel: 'I am a p tag' } );

More complex
A Node that is a ul tag that holds children, but also has a label and a description

new Node( { 
   tagName: 'el', 
   accessibleLabel: 'Unordered List',
   labelTagName: 'h3',
   accessibleDescription: 'I am an unordered list' } );

This will yield the following structure in html

<ul> node
   <h3> label
   <p> description
   <-- any children here -->

Now another use case is that we want this Node to have a label, a description, and have children, just like above, but we want the label/description to be before the node, in which case we surround everything in a div and the html looks like:

```html
<div> surrounding div
   <h3> label
   <p> description
   <ul> node
      <-- any children here -->

In this case it is sometimes nice to have a description tag with a bit more "power". Since we can't create other p tags that live as a sibling to these h3, p, or ul tags. Potentially we could use the br tag to make that description p tag more complex. I'm not sure if we really want this, but the example where I would want to use it is in Ohms Law with the circuit to separate: "A pair of wires connect a resistor to a series of batteries." from "In circuit, ". That extra pause may help emphasize the introduction to a list, like what "Right now, " does in the scene summary.

Final thoughts:

• Is this a use for a br tag?
• I'm no designer, and I don't have a preference as to how we do things, I just thought this could help.
• I'm happy to talk in person to clear up any communication shortcomings of the above scenarios.
• I'm not sure this is a very important feature, but it may be nice to be able to simplify the code a bit in some places.

[zepumph]

I don't think that br tag support is necessary, especially because of work in #686