implemented header

[jwoo-msft]

Related Issue

Fixed #7529

Description

Added Header according to #7529

Sample Card

CarouselHeader.json

Microsoft Reviewers: Open in CodeFlow

[ghost]

Hi @jwoo-msft. Thanks for helping make the AdaptiveCards JS renderer + tooling better. As additional verification, once the JS build succeeds, please go to the test site to test out your website/designer changes.

[JeanRoca]

Based on how the schema was implemented in https://github.com/microsoft/AdaptiveCards/pull/6667 I thought that the Carousel was only allowed to show if it was the only element inside of body as specified with the body: { } syntax instead of body: [ ].

I just did some testing and currently it seems that other elements are allowed to be on an Adaptive Card with a Carousel. Here is an example:

{
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "type": "AdaptiveCard",
    "version": "1.6",
    "body": [
        {
            "type": "Container",
            "items": [
                {
                    "type": "TextBlock",
                    "wrap": true,
                    "text": "These are cat pictures",
                    "style": "heading",
                    "fontType": "Default",
                    "size": "ExtraLarge",
                    "weight": "Bolder"
                }
            ]
        },
        {
            "type": "Carousel",
            "timer": 5000,
            "pages": [
                {
                    "type": "CarouselPage",
                    "id": "firstCarouselPage",
                    "selectAction": {
                        "type": "Action.OpenUrl",
                        "title": "Click for more information about the first carousel page!",
                        "url": "https://adaptivecards.io/"
                    },
                    "items": [
                        {
                            "type": "Image",
                            "url": "https://adaptivecards.io/content/cats/1.png",
                            "altText": "Cat",
                            "size": "Medium"
                        }
                    ],
                    "rtl": false
                },
                {
                    "type": "CarouselPage",
                    "id": "theSecondCarouselPage",
                    "items": [
                        {
                            "type": "Image",
                            "url": "https://adaptivecards.io/content/cats/2.png",
                            "altText": "Cat with bandana",
                            "size": "Medium"
                        }
                    ],
                    "rtl": false
                },
                {
                    "type": "CarouselPage",
                    "id": "last-carousel-page",
                    "items": [
                        {
                            "type": "Image",
                            "url": "https://adaptivecards.io/content/cats/3.png",
                            "altText": "That's a cool cat!",
                            "size": "Medium"
                        }
                    ],
                    "rtl": false
                }
            ],
            "rtl": false
        }
    ],
    "actions": [
        {
            "type": "Action.OpenUrl",
            "title": "See more",
            "url": "https://adaptivecards.io"
        },
        {
            "type": "Action.OpenUrl",
            "title": "Another action",
            "url": "https://adaptivecards.io"
        }
    ]
}

On the preview designer site this renders:

This can achieve the same outcome as a header, but it can also lead to some broken experiences like:

@paulcam206 any idea why this is rendering in the Designer even though the schema should not be allowing this?

I am not sure what other broken experiences might arise from this behavior so I think @jwoo-msft change in this PR should be what we go with.

[anna-dingler]

@JeanRoca I ran into this as well when I made my carousel changes. My open PR (https://github.com/microsoft/AdaptiveCards/pull/7654) should only allow the carousel elements in an object body {}.

You can try these out on the test site for my PR - https://adaptivecardsci.z5.web.core.windows.net/pr/7654

[paulcam206]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument).

It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header?

@JeanRoca / @jwoo-msft

[jwoo-msft]

@JeanRoca I ran into this as well when I made my carousel changes. My open PR (#7654) should only allow the carousel elements in an object body {}.

You can try these out on the test site for my PR - https://adaptivecardsci.z5.web.core.windows.net/pr/7654

Yes, this pr is assuming 7654 pr is in.

[jwoo-msft]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument).

It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header?

@JeanRoca / @jwoo-msft

TextBlock makes senses to me.

[JeanRoca]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument).

It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header?

@JeanRoca / @jwoo-msft

I'm sorry I don't think I understand this entirely.

Is the suggestion here to use TextBlock instead of RichTextBlock in order to take advantage of the a11y features that were added in 1.5?

What are the disadvantages of going with RichTextBlock over TextBlock?

[jwoo-msft]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument). It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header? @JeanRoca / @jwoo-msft

I'm sorry I don't think I understand this entirely.

Is the suggestion here to use TextBlock instead of RichTextBlock in order to take advantage of the a11y features that were added in 1.5?

What are the disadvantages of going with RichTextBlock over TextBlock?

@JeanRoca TextBlock has style property, and the one of the style property is heading. if the style is set heading, the renderers set heading as a11y role for the text.

[JeanRoca]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument). It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header? @JeanRoca / @jwoo-msft

I'm sorry I don't think I understand this entirely. Is the suggestion here to use TextBlock instead of RichTextBlock in order to take advantage of the a11y features that were added in 1.5? What are the disadvantages of going with RichTextBlock over TextBlock?

@JeanRoca TextBlock has style property, and the one of the style property is heading. if the style is set heading, the renderers set heading as a11y role for the text.

I see thank you for clarifying @jwoo-msft . Based on my understanding here, it seems we have two options:

Option 1: The supported element for a carousel header is a TextBlock. With this option, we have access to the style property of "Header" that sets the a11y role.

Option 2: The supported element for a carousel header is a RichTextBlock. With this option, we gain the ability for inline styling text, but lose the ability to set the Style property of "Header" that sets the a11y role.

I think going with option 1 makes sense here. The only thing I am concerned about is the following scenario:

I think that this scenario would only be possible if RichTextBlock is used as different lines have different styles. The main functionality of having a header can be achieved with just TextBlock and this will solve our customer's request. Allowing for multi-line styling is currently a nice to have.

Is there any way we could achieve a similar outcome by only using TextBlock?

[jwoo-msft]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument). It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header? @JeanRoca / @jwoo-msft

I'm sorry I don't think I understand this entirely. Is the suggestion here to use TextBlock instead of RichTextBlock in order to take advantage of the a11y features that were added in 1.5? What are the disadvantages of going with RichTextBlock over TextBlock?

@JeanRoca TextBlock has style property, and the one of the style property is heading. if the style is set heading, the renderers set heading as a11y role for the text.

I see thank you for clarifying @jwoo-msft . Based on my understanding here, it seems we have two options:

Option 1: The supported element for a carousel header is a TextBlock. With this option, we have access to the style property of "Header" that sets the a11y role.

Option 2: The supported element for a carousel header is a RichTextBlock. With this option, we gain the ability for inline styling text, but lose the ability to set the Style property of "Header" that sets the a11y role.

I think going with option 1 makes sense here. The only thing I am concerned about is the following scenario:

I think that this scenario would only be possible if RichTextBlock is used as different lines have different styles. The main functionality of having a header can be achieved with just TextBlock and this will solve our customer's request. Allowing for multi-line styling is currently a nice to have.

Is there any way we could achieve a similar outcome by only using TextBlock?

@JeanRoca TextBlock's size applies to all of the text. MarkDown can be used to set bold and italic in section of text and that's about it. If the new scenario is to be supported, 'header' property should be changed to different name, and instead of having a single TextBlock, we need a container. for example, instead of 'header', change it to something like 'staticContent' and have its value to be a Container. We could also add style to TextRun, and that would impact other renders meaning they are needed to be updated. Can you gather all the requirement regardless how important they are?

[JeanRoca]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument). It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header? @JeanRoca / @jwoo-msft

I'm sorry I don't think I understand this entirely. Is the suggestion here to use TextBlock instead of RichTextBlock in order to take advantage of the a11y features that were added in 1.5? What are the disadvantages of going with RichTextBlock over TextBlock?

@JeanRoca TextBlock has style property, and the one of the style property is heading. if the style is set heading, the renderers set heading as a11y role for the text.

I see thank you for clarifying @jwoo-msft . Based on my understanding here, it seems we have two options: Option 1: The supported element for a carousel header is a TextBlock. With this option, we have access to the style property of "Header" that sets the a11y role. Option 2: The supported element for a carousel header is a RichTextBlock. With this option, we gain the ability for inline styling text, but lose the ability to set the Style property of "Header" that sets the a11y role. I think going with option 1 makes sense here. The only thing I am concerned about is the following scenario:

    [
      
        ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
      
    ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
    
      
        
          
        
        
          
          
        
      
      [
        
          
        
      ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
   [ ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif) ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
  
    [
      
        ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
      
    ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
    
      
        
          
        
        
          
          
        
      
      [
        
          
        
      ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
   [ ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)

I think that this scenario would only be possible if RichTextBlock is used as different lines have different styles. The main functionality of having a header can be achieved with just TextBlock and this will solve our customer's request. Allowing for multi-line styling is currently a nice to have. Is there any way we could achieve a similar outcome by only using TextBlock?

@JeanRoca TextBlock's size applies to all of the text. MarkDown can be used to set bold and italic in section of text and that's about it. If the new scenario is to be supported, 'header' property should be changed to different name, and instead of having a single TextBlock, we need a container. for example, instead of 'header', change it to something like 'staticContent' and have its value to be a Container. We could also add style to TextRun, and that would impact other renders meaning they are needed to be updated. Can you gather all the requirement regardless how important they are?

@jwoo-msft I went ahead and added the requirements we have in #7529. Let me know if you have any questions on those and I'll be happy to help.

[jwoo-msft]

I have a spec question about accessibility -- in schema 1.5 we added the style property to TextBlock, which allows a card author to indicate that a given TextBlock serves as a section header. Under the hood, this is wired up to a11y properties so that it's exposed property to AT. It doesn't look like we extended this same functionality to RichTextBlock, presumably because RichTextBlock is probably a bit too featureful for use as document section headers (though I don't remember the discussion around this well enough to know if that was the argument). It feels to me like it should be possible (or even default behavior?) for the element in the header here to be marked as a header? @JeanRoca / @jwoo-msft

I'm sorry I don't think I understand this entirely. Is the suggestion here to use TextBlock instead of RichTextBlock in order to take advantage of the a11y features that were added in 1.5? What are the disadvantages of going with RichTextBlock over TextBlock?

@JeanRoca TextBlock has style property, and the one of the style property is heading. if the style is set heading, the renderers set heading as a11y role for the text.

I see thank you for clarifying @jwoo-msft . Based on my understanding here, it seems we have two options: Option 1: The supported element for a carousel header is a TextBlock. With this option, we have access to the style property of "Header" that sets the a11y role. Option 2: The supported element for a carousel header is a RichTextBlock. With this option, we gain the ability for inline styling text, but lose the ability to set the Style property of "Header" that sets the a11y role. I think going with option 1 makes sense here. The only thing I am concerned about is the following scenario:

    [
      
        ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
      
    ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
    
      
        
          
        
        
          
          
        
      
      [
        
          
        
      ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)

    [
      
        ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
      
    ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
    
      
        
          
        
        
          
          
        
      
      [
        
          
        
      ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
   [ ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif) ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
  
    [
      
        ![Carousel2](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
      
    ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
    
      
        
          
        
        
          
          
        
      
      [
        
          
        
      ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)
    
   [ ](https://user-images.githubusercontent.com/33772802/182461142-f3d53844-105e-4928-a7f3-ed1d50925eb3.gif)

I think that this scenario would only be possible if RichTextBlock is used as different lines have different styles. The main functionality of having a header can be achieved with just TextBlock and this will solve our customer's request. Allowing for multi-line styling is currently a nice to have. Is there any way we could achieve a similar outcome by only using TextBlock?

@JeanRoca TextBlock's size applies to all of the text. MarkDown can be used to set bold and italic in section of text and that's about it. If the new scenario is to be supported, 'header' property should be changed to different name, and instead of having a single TextBlock, we need a container. for example, instead of 'header', change it to something like 'staticContent' and have its value to be a Container. We could also add style to TextRun, and that would impact other renders meaning they are needed to be updated. Can you gather all the requirement regardless how important they are?

@jwoo-msft I went ahead and added the requirements we have in #7529. Let me know if you have any questions on those and I'll be happy to help.

love it

[ghost]

Hi @jwoo-msft. This pull request has had no recent activity for the past 5 days . Please take the necessary actions (review, address feedback or commit if reviewed already) to move this along.

[ghost]

Staleness reset by jwoo-msft

[ghost]

Hi @jwoo-msft. This pull request has had no recent activity for the past 5 days . Please take the necessary actions (review, address feedback or commit if reviewed already) to move this along.

[ghost]

Staleness reset by jwoo-msft