Tumgik
#which I desperately need if I don't want to keep doing battle with the litter boxes
icedteaandoldlace · 2 years
Text
Very busy, productive day today. I cleaned out all the junk that's been sitting in my room for ages (other people's junk btw), swept, dusted, mopped, cleaned the walls, got rid of my broken blinds, moved some furniture around, and got Dad to take a look at it when it was all finished so he could see what needs to be done to get the place fixed up. He has a couple things he has to get done first, but soon he'll get started fixing the leak in my roof, and he'll probably have to tear down my walls, at least partially, and get them replaced due to the water damage. After that, the plan is to buy a new bed and move it into the fixed up half of the room, and junk my current bed while he fixes up the other half. Once that's done, I can move my bookshelves out of my closet and maybe set the area I have my bed in now up to be a little library/sitting area/dressing room.
3 notes · View notes
softxsuki · 2 years
Note
Hi there, so may I please make an urgent request.
A 'friend' of mine were in a call with 2 other friends of mine, my 'friend' started saying how she was going to cut her arm on call. She then actually showed her wrist and revealed all the cuts on her arm. It made me feel so incredibly uncomfortable since I am struggiling with self-harm. I've been clean since november, but her scars made me feel a need to do it again. I know I shoud be comforting her and I did, I tried. But she she wouldnt listen. She kept brushing it off like it was nothing. She had to yell at me about it to make me stop.
Im really trying my hardest not to relapse. im trying so hard, i dont want to do it again.
I don't have any friends who are good comforters, if i we're to vent to them they'd all just turn it into some sick fucking joke.
My comfort character is Sugawara and as of right now, I just really want to distract myself or get atleast a little bit of comfort for this.
Maybe a scenario where Suga finds reader in the bathroom with the blade against their skin, they havent done anything yet but are really thinking of it. We open up to him and he comforts us and reassures us that it's gonna be okay.
Though, this is an urgent request. Please feel free to take your time on this one and take lots of breaks. Thanks<3
Sugawara Comforts Reader Who Wants to Self-Harm Again
Pairing: Sugawara x Gn!Reader
Warnings: kinda graphic descriptions of self-harm, mentions of blood (no cutting actually happens though) please skip over any parts that might trigger you. I'll highlight them in red, so if it's something that might do you more harm than good, please skip over it :(
Genre: Comfort
Post-Type: Oneshot
Word Count: 1.2k
Summary: In which Sugawara catches you in the bathroom with a razor in your hand as you contemplate over self-harming
[A/N: Hey! That wasn't very nice of your 'friend' to be so insensitive like that to you. But that's good that you still tried to comfort her even if it didn't work. I'm sorry that your friends aren't very good at comforting you. It's horrible to think that someone would turn your situation into a joke whenever you seriously reach out for help. Hopefully this oneshot can give you a bit of comfort as Sugawara reassures you and tells you that everything is going to be okay. TW: MENTION OF SELF-HARM--I know you probably hear this a lot, but I went through the same thing from 8th grade to 10th grade and it was hard stopping, especially when it became a habit, BUT here I am almost seven years later and I feel no urges to hurt myself anymore. But the scars are still on my thigh so I definitely regret that, but it is what it is. They're reminders of that battle that I finally won! And you will be victorious as well, so keep fighting! I believe in you. I'm here if you ever need anyone to talk to or listen to you <3 Take care and stay tough :D]
Tumblr media Tumblr media
Tears run down your face as you feel the cold metal of the blade in your hand against your wrist, taunted by the faded marks already littered across your skin. The shower was on, soaking you and your clothes that you couldn’t be bothered to take off. Your tears blend in with the water dripping down on you, desperately wishing that these horrible feelings of harming yourself would just go away.
“Just do it,” a voice in your head screams while a much softer voice begs you not to. Which one would you listen to? You weren’t sure, but the louder voice sounded tempting.
You had been clean for a few months, the litter of old scars on your arms were proof that you hadn’t given in for months, but it was so easy to get the urge to harm yourself back in your head. The razor was so close, but you hadn’t made a move yet, knowing what would happen if you just turned your mind off and gave in.
You thought you were home alone, assuming that Sugawara had Volleyball practice or something, so when you heard a knock along with his voice speaking from the other side of the bathroom door, you paused.
“Hey I just need to use the bathroom real quick, I won’t look!” He announces himself outside the bathroom before pushing the door open.
You were too stunned to move, your razor still positioned on your wrist as you looked up at him wide-eyed. He notices you sitting with the shower on, fully clothed and then his eyes drift slowly to the razor in your hand.
“What are you doing?” He asks in shock, slowly moving towards you.
Once he reaches you, he quickly shuts the water off before cautiously reaching for the razor in your hands, breathing out in relief when he manages to take it from your hands and see’s that you weren’t hurt. You’re full on sobbing now, soaking wet from head to toe, your soaked clothes weighing you down as you apologize profusely to him.
“I didn’t mean it,” you stutter, trying to stop the tears from falling down your face, “I didn’t know what to do, the urge to do it just suddenly came over me!”
“I know darling, it’s okay,” he says softly, reaching over for you, not caring that you were getting him wet as he lifts you out of the tub and into his arms onto the bathroom floor with him, “everything’s going to be okay, leave everything to me now. You don’t need to worry about anything.”
He presses soft kisses to the top of your head and wipes away your tears before reaching for a towel and gently drying you off as best as he could. He wraps the towel around you as you begin to shake from the cold air that felt ten times more cold since you were soaking wet.
“I was doing so well, and I almost just ruined it all…” you mumble as the weight of the situation finally comes crashing down on you.
“No baby, don’t be so hard on yourself. You’re doing an incredible job. I know it’s not easy, but you’ve made it this far and I’ll help you make it even further without hurting yourself again. You can do this. You’re so strong and I’m so proud of how far you’ve come. No one’s perfect, we’re bound to fall and slip up here and there, but thankfully I made it in time to stop you.”
You lean back onto his chest, letting his words soak into your heart and mind, thankful that he did make it in time to stop you. You know you’d regret hurting yourself again. You would never forgive yourself if Suga had walked into that bathroom and witnessed a blood bath as you carved into your own skin. But you did feel bad that he had to witness you at such a low moment after months of doing so well, you wish he would never see you like that again.
“I’m sorry you had to see that. I’m a mess right now,” you sigh now fully feeling the heaviness of your wet clothes that weighed down on you, still shivering slightly.
“It’s okay. I’m just glad you’re fine. Please come to me whenever you feel like this again so I can try to help you before your feelings get this far out of control. I don’t want you to feel guilty about your actions and blame yourself,” he reassures you.
You nod in agreement. Just simply talking to him on the bathroom floor made you feel a lot better, so next time you would definitely reach out to him so you wouldn’t have to give in to your negative thoughts that always want to bring you back to the way you were months ago.
“Let’s get you out of those wet clothes before you get sick. You can take a nice warm shower to warm yourself up and I’ll go get you a change of clothes. I can sit right here and talk to you if you want–just so you’re not alone,“ he offers you, as he helps you get back onto your feet.
“I’d like that, thank you Suga.”
So you strip out of your drenched clothes and run yourself a hot shower, sighing in relief under the warm water that felt a lot more comforting than it did earlier. A few minutes later you hear a soft knock at the door along with Sugawara's voice as he enters for the second time that night.
“I got your clothes, so I guess I’ll just sit here and talk to you if you want. I’ll leave once you need to come out and get dressed, unless you’d prefer if I just leave now.”
“No, stay!” You say a little too quickly, embarrassed at the desperation in your voice.
“Okay great. I wanted to stay anyway,” you could hear the smile in his voice, he really knew how to make you feel so calm. Maybe it was the tone of his voice or just the way he spoke, it made shivers run down your spin as light filled your heart.
He began speaking about his day, never mentioning what he had witnessed a few minutes earlier and you were grateful for that. You didn’t need to have him treading cautiously around you, worried that he might say the wrong thing or have him watch you like a hawk, scared that you’ll slip up again–that would make you feel like there was something wrong with you. It was nice to have normalcy in that moment with him, as if things were fine. His words from earlier about offering for you to come to him if you needed him, played in your head and you knew you could. You felt like it would be okay to go to him about any of your worries or emotions.
“Hinata and Nishinoya were goofing off so much today during lunch. It was hilarious Y/N, I wish you could have seen it,” he continues talking about his day, stopping frequently to see if you had anything to add.
You smile at his rambling, just enjoying the sound of his voice as your worries wash away with the water down the drain. You were relieved that you were still clean from self-harm and hoped that you could continue to be clean until the urge to harm yourself no longer hung over your head. But even if you did happen to slip up and ruin that clean streak, you knew Sugawara would still be by your side motivating you to push forward and try again.
You could do it. You would do it!
Tumblr media
REQUESTS ARE OPEN :D
Posted: 1/25/2022
71 notes · View notes
Text
"Please don't leave me" ~ Peter Parker
Summary: When you are injured in battle Peter begs you to stay
Word Count: 3.4k
Pairing: Peter Parker x Fem!Speedster!Reader
Warnings: Mentions of violence, death, injuries, and blood. Just overall sad. (If we missed something that you feel should be tagged and/or mentioned let us now and we'll include it)
A/N: Hey, so as you can see we are not dead! :) (I don't know why I did that it hurt me too ok?) Since there was no post in March we are going to try our best to post two other one shots this month, but we'll see how that goes. Hope you all enjoy this and have a great morning/afternoon/night! -W&C :)
Also major thanks to @apotatoinabigfield and @too-attached-to-fiction for proofreading and beta-reading this!
Tumblr media
*GIF IS NOT OURS* (We got it off of Google, but if anyone knows who the credits for it belong to let us know so we can rightfully tag them)
5 years ago:
“Something’s happening,” said the girl with the antennae, Mantis. At least, that’s what she had said her name was. Suddenly after, she turned to dust. She just disappeared. In shock, you got closer to Peter, looking for some kind of safety or comfort. Everyone was shocked; no one could understand what had just occurred before your very eyes. Before anyone could say something or even gather their thoughts, it happened again.
“Quill?” was the last thing Drax said before suffering the same fate as Mantis. We lost. That was the only explanation you could fathom. The Avengers had lost and Thanos won. You tightened your grip around Peter, fully embracing him now. You were all desperately trying to decipher who would be next, fearing it being yourselves or your loved ones, but it was pointless. Whatever was causing this came and left without a warning.
“Steady, Quill,” said Tony, but it was to no avail.
“Oh, man,” sighed the man who had introduced himself as Starlord, dusting away defeatedly. You looked up at Peter, who had wrapped his arms around you in a protective manner. He was scared, that much you could tell, but he wouldn’t meet your eyes, determined to conceal the unsettling fear of not being able to hold you for much longer. You tried to convince yourself it was done—that no one else would be taken—but it was pointless. Deep down, you knew this was far from over.
“Tony,” the man turned to look at Strange, “there was no other way.” Stephen Strange took a couple more breaths before dusting away like the others had. Although Strange had said he saw over sixty-three billion outcomes, you couldn’t see how this could be the one you won in. It definitely didn’t feel like it.
Suddenly, breathing became hard. You saw dust particles floating from your hand and the reality of what was going to happen hit you. “No,” you whispered anguishly.
“(Y/N)?” Peter brought your attention to him instead of the particles which declared your fate.
“Pete, I—” you started as you reached up to stroke his cheek, but before you could come in contact with his skin or finish your declaration, you faded away in his arms.
“I know,” the boy said softly as he watched the wind carry what was once his lover.
Tony was at loss for words. He felt like the universe was playing a sick, twisted prank on him. As Tony sulked, Peter felt it. He felt his spidey sense warn him that something was going to happen. He could feel his body struggle to keep him in one piece, to keep him together, to keep him alive. No matter how quickly his body fought, it was destined to lose. “Mr. Stark,” the boy called out to the man who was more than his mentor, the man who had become like a father to him.. “I don’t feel so good,” he painfully admitted. Peter started stumbling around, his legs struggling to keep him up.
“You’re alright,” defied Stark. More than an attempt to console the boy, Tony Stark was trying to reassure himself that the universe, as cruel as it had always been to him, wouldn't do this—that it would not take his boy away. But alas, the genius man was to be proven wrong.
“I— I don’t know what’s happening. I— I don’t understand,” countered the Spiderboy hurriedly. His feet gave out, and he would’ve fallen forward if it hadn’t been for Tony catching him and holding him up. More and more particles could be seen emerging from the boy, and in that moment, the only thing Tony could do was hold on to Peter for as long as he had left.
“I don’t wanna go,” Peter pleaded. “I don’t wanna go, Mr. Stark, please.” His voice was cracking and his legs couldn’t support him any longer as more particles escaped him. Peter’s pleas wouldn’t cease much like the cracks in his voice every time he spoke. Tony lowered him to the ground not daring to say a word. Peter, with teary, bloodshot eyes, looked at the man and whispered an apology before finally letting his body dissipate.
Tony couldn’t speak; he couldn’t even think. “He did it,” said Nebula. Yet the genius, billionaire, playboy, philanthropist didn’t respond. He just looked at his hand, which was covered in dirt—dirt that had once been Peter Parker. Tony let himself cry, allowing grief and shock to take over him. After all there was nothing else he could do.
***
Present day:
“Love you—wait, what happened?” You find yourself reaching up, but the person you had been trying to touch no longer stood in front of you. Your body was slowly regaining feeling, but your mind felt as numb as ever. You had so many thoughts running through your brain at such a speed that you couldn’t focus on any of them.
“I love you too, Speedy.” You heard a voice answer from behind you. You felt some of the anxiety subside once you put a name to the voice, which was easy since only one person in the entire world called you Speedy.
“Peter,” you exhaled in relief. Turning around in an instant, you ran into the arms you had chosen to call home. Peter embraced you tightly, not wanting to release the other in fear of permanently losing one another this time. You didn’t know how much time had passed from when you lost your consciousness, but that didn’t matter for Peter. Seeing the person he had deemed to be his soulmate dissipate in front him had been more than enough for him to feel like the amount of time that had passed between then and now had been an eternity. Suddenly, Strange spoke up, answering the question plaguing everyone’s minds.
“It’s been five years. Come on, they need us.” He stated commandingly. You all shared looks of dumbfoundment and bewilderment. Five years? How could that have been possible? The only one on the planet you stood on who looked at ease was Stephen, his calm demeanor never faltering. You looked up at Peter confused, but he simply shrugged, not wanting to believe such time had passed yet knowing better than to contradict Dr. Strange.
“Okay, everyone, this is it. Activate your badass stances!” exclaimed Quill.
“What did you say about my ass, Quill?” Drax started charging towards him, visibly offended. You raced to wedge yourself between the two men, struggling to keep them apart.
“Hey, no time for that. Look!” You called over their attention to the portal Strange was opening in front of you. Peter swung his way to the front, landing elegantly. After making sure Quill and Drax would not try to go at each other's throats, you swiftly made your way to the front and stood beside Peter.
Glancing around what was going to serve as your battlefield for today, you grimly recognized the location. What was once known as the Avenger’s Headquarters was now no more than a field of scattered debris. Clouds of dust littered the air, the remains of mass destruction visible wherever you looked. You gave yourself a chase to take in the sight of Thanos’ army, and as you did so, fear and worry tried to etch their way into your brain as you realized what you were facing. This was an enemy that had already defeated you once, and when you had fought him, he hadn't even had an army backing him up. Your determination and will to fight and live to tell the tale overpowered those negative feelings. The sight of the spaceship filled you with spitefulness instead of dread, and you knew in that moment that you would do whatever it took to win. The Avengers would not lose again; you were going to make sure of that, even if you had to lay down your life for it to become a reality.
“Is that everyone?” Strange asked Wong.
“What, you wanted more?” Wong yelled back in disbelief, and Strange shrugged nonchalantly in response.
As everyone settled into position, Cap’s voice was loudly heard, like thunder rumbling through the field, “AVENGERS.” This was the moment of truth—your last chance to save humanity. You could feel the seconds pass before Steve gave the signal, “Assemble.” And with that, everyone was off.
A beautiful and empowering mess of battle cries could be heard around you. You, on the other hand, were silent as you ran, calculating your every move. Using all the knowledge you’d gained over the years about hand-in-hand combat, you started to hastily assassinate those monsters. You would jump at one, taking them down, and godspeed to your next target, sending each one you came in contact with on a one way trip to meet their maker. Near you, Peter was also taking out some of the Chitauri, at times propelling you onto your next target or eliminating some of them when you got surrounded. After clearing out most of the aliens near you, Peter tapped you on the shoulder and pointed to Tony. Understanding his intentions, you nodded and made your way towards the infamous Iron Man.
As you slid into the crater where Tony lay, Peter landed from his swinging. Tony stared at the two of you in disbelief, doubting whether or not to believe you were actually there. When his expression softened, and tender affection spread across his factions, Peter began rambling, and you shook off some of the concrete dust from your suit. “Hey, holy cow! You will not believe what’s going on,” Peter exclaimed as he helped Tony stand up.
“No?” Tony asked sarcastically, but it only encouraged you.
“Do you remember when we were in space? And we got all dusty? I guess we must’ve passed out because when we woke up, you were gone.” You now stood beside Peter as you spoke, your hands increasing their pace as you rambled on, making them impossible to follow with the human eye.
“But Doctor Strange was there right? He was like ‘It’s been five years. Come on they need us,’” Peter said as he tried to make an impression of Strange, mimicking the way the man had moved his hands when opening the portals.
“Yeah, and then he started doing the yellow sparkly thing he does all the time.” You took over from Pete when he gave you the chance.
“He did? Oh, God!” Tony exclaimed with feigned incredulity. He started walking toward you and grabbed you both by the shoulder, pushing you into him.
“What are you doing?” Peter asked, bewildered.
“Huh, what’s this?” You questioned, confused as Tony engulfed you both simultaneously. He held you tightly, and when the shock passed, you and Peter hugged the man back even tighter.
“Oh, this is nice.” Peter sighed, earning a light chuckle from Stark.
“Listen, kids, we don’t have a lot of time right now, but I’ll catch you up on the latest trends once we take this bitch down. Okay?” Tony assured as he released you, holding on to your forearm to look the both of you in the eyes as he spoke.
“Yes, sir.” Peter saluted.
“See you on the other side of the war.” You smirked, knowing Tony and Peter must have caught that reference. Tony shook his head as he took off, the ghost of a grin barely noticeable on his lips.
Peter nudged you. “Be careful, okay?” His eyes showed genuine concern.
“Alright, I solemnly swear—” Peter gave you a warning look. “Okay, fine. I’ll try my best to be as careful as possible in the middle of a battle.” You finished, your tone a weird mixture between sarcasm and affection.
“Good.” He pressed a quick kiss to your temple before taking off.
“Alright, Chitauri, give me your best shot.” You smirked at the unsuspecting figure that was currently fighting off T’challa. Having speed and regeneration to your advantage, you zig-zagged around Thanos’ army, ducking and killing as you went. You moved with precision, only stopping when you were sure to have a clear shot at the enemy you were targeting.
You went on that way until you weren’t able to dodge a body that dropped in front of you, making you trip over it. The collision made you roll down a mountain of debris, hitting your head dangerously hard several times, as well as getting a couple of cuts along the way from the exposed, sharp metal.
“That’s sure to give me a concussion,” you grunted to yourself. The throbbing of your head distracted you from the burn of the cuts that now littered your abdomen, some deeper than others. It wasn’t until you brought a hand to your head, that you noticed the crimson liquid that coated it. “Oh, shit,” you exhaled. The pain was starting to catch up to you as the adrenaline subsided. You tried to use your powers to find yourself a safe spot until you recovered, but your attempts were futile seeing as the pain coursing through your body rendered you immobile.
“Is that Peter falling?” The figure you saw was indeed Peter and the sharp spiderlegs of his suits were still out for blood. You managed to move just enough that you were barely graced, another gash prompting blood out of your system. Peter tumbled in the opposite direction, clutching what you assumed to be the gauntlet you were supposed to keep out of Thanos’ hands. The sudden movements to dodge Peter hadn’t come without consequences. You felt like your surroundings were spiralling around you, dizziness overtaking you as you started to cough up blood. You managed to stubbornly sit up and when you looked to your side, you saw Peter giving the gauntlet to a glowing woman.
“I don’t know how you’re gonna get it through all that,” you heard him admit to her out of breath.
“Don’t worry,” Wanda stepped in.
“She’s got help,” Okoye finished, her hands wrapped tightly around her spear. Soon the rest of the women joined and took off together. It was a powerful moment to witness and one you would’ve loved to be a part of, if it weren’t for your current situation. You closed your eyes in a somewhat successful effort to ease off the pain pulsating in your head.
“Man, those are some badass women,” Peter muttered as he sat down. “Wait—” He quickly looked around, but missed you completely. “Where’s my badass woman?” Peter frantically shuffled to his feet, hoping to see a flash of yellow zoom by, but no such luck. You tried to call out to him, wanting to let him know you were there, but your voice got caught in your throat, replaced by a cough that was followed by blood. The sound caught Peter’s attention, his gaze trying to find where it came from. His heart constricted in his chest when he finally caught sight of you and the state you were in.
In a flash, he was hovering over you, putting your own abilities to shame given the speed at which he got to you. Your eyes were still closed, as you relished the relief it gave you, but you were drifting off at this point and didn’t have the energy nor strength to open them again. That was until Peter started shaking you awake. “(Y/N)? Oh God, come on, please be okay.” You could hear the panic and desperation in his voice. Your eyes felt so heavy, it was almost impossible to open them, but you managed to do so, just enough to see Peter exhale in relief after seeing you respond.
Tucked away behind blood and dryness, you managed to find your voice and you raspily told him, “I’m okay, Peter. It’ll heal. Go help the others.” You took ragged breaths between each sentence, your lungs struggling to keep up. Peter could very much tell you weren’t okay and knew that with the amount of injuries you had suffered it was almost impossible for your regenerative abilities to save you.
“(Y/N), we both know that’s not happening; it’s too much. I mean, it might heal, but there are too many things to heal for you to survive waiting and—” He abruptly stopped his own rambling after he noticed you had closed your eyes again. “(Y/N)? (Y/N), please, stay with me.”
His voice was breaking and his eyes were starting to swell up with tears. It broke your heart to hear him like this. You fought to stay conscious, for his sake, but the blood loss and pain was becoming too great to bear and you felt yourself falling into a deep slumber once more.
Peter was getting desperate, tears freely flowing down his cheeks now. “Please, (Y/N/N), please don’t leave me.” He held your body close to his, burying his face in the crook of your neck. Sobs rocked his body as he kept begging for you to stay. His voice and your tear stained neck was the last thing you registered before you let go and fell into the dark abyss of unconsciousness.
***
“Everybody wants a happy ending, right? But it doesn’t always roll that way. Maybe this time, I’m hoping if you play this back, it’s in celebration. I hope families are reunited, I hope we get it back, and something like a normal version of the planet has been restored. If there was ever such a thing. God, what a world! Universe, now. If you told me ten years ago that we weren’t alone, let alone, you know, to this extent, I mean I wouldn’t have been surprised. But come on, you know? The epic forces of darkness and light that have come into play. And for better or for worse, that’s the reality Morgan’s gonna have to find a way to grow up in. So, I thought I’d probably better record a little greeting... In case of an untimely death on my part. I mean, not that death at any time isn’t untimely. This time travel thing that we’re gonna try and pull off tomorrow, it’s—it's got me scratching my head about the survivability of it all—that’s the thing. Then again, that’s the hero gig. Part of the journey is the end. What am I even trippin’ for? Everything’s gonna work out exactly the way it’s supposed to. I love you 3,000.”
Pepper walked out of the cabin she and Tony had called home, holding a wreath that in its middle held Tony’s first arc reactor. Everyone stood out in front of the lake, waiting as she gently placed it on the water. She took her place beside Peter, who was silently crying as he held your emotionally devastated self in his arms. Having passed out when you did had ultimately saved your life, your body using its remaining energy in healing you rather than keeping you awake, but that meant you missed the events that led up to your victory and were therefore unable to say a proper farewell to the man who served as your mentor for years.
Waking up to the news that the man who had taken better care of you and had looked out for you more than your own parents was dead didn’t settle in easily. It took a while before you were able to accept he was gone.
Peter had been there for you every step of the way, holding you during all the sleepless nights you had spent crying and shaking you awake when your dreams became plagued with nightmares from the battle. Guilt had made a home in your heart, the feeling never leaving as you thought of ways you could have avoided getting injured, ways you could have fought better, ways that could have resulted in being able to say goodbye to Tony Stark, the man who sacrificed himself for the universe.
Everyone stood silently as you all watched the wreath float out of sight, before turning to share your condolences with each other. You held on to Peter tightly, as if he too were to slip from your fingers at any moment. You stood there mindlessly listening in on the nostalgic conversations between the people who cared for Tony. Looking around at everyone gathered, it became clear that the arc reactor which was now floating off in the lake was not the only proof that Tony Stark had a heart. All his friends, colleagues, family and adopted students were walking proof that not only did Tony Stark have a heart, but that he had the biggest heart a human could possibly have.
Taglist: @steveisherdaddy @apotatoinabigfield @xlostinobsessionsx @izjustafaze @yourlocalwhitemanwhore
180 notes · View notes
clairen45 · 6 years
Note
Hey, fantastic job with your metas! I don't know if you've already posted a thorough article on what you expect or think IX will be, but I'd love to read what you have to say about the probable storyline you think is going to happen; personally, I'm having a hard time believing the Reylo arc can be completed in just another movie, let alone the arcs of the three trilogies; what would be left for the next trilogy they're already working on? What do you think? Tks again!
Dear Anon,
thank you for being so encouraging, it is always nice to hear! And thanks for the ask. It took me a little while to answer you (sorry about that) because I was wondering what I could really tell you. I usually try to avoid speculations because, well, I would not say it is my forte, I am not the best at making bets… And, honestly, there is a lot of stuff that could go whatever… BUT…. There are some things I think we can count on, and some things we may expect. And some others (not necessarily groundbreaking) that we could also see them explore or hint at, when looking at the material they have given us so far. Again, I will not bet on anything…Disclaimer, guys!
What we can count on:
Ben’s redemption (yep), last Skywalker standing, guys…. This is my final world, and I have no doubt about that. 
More Force bonds. Because they are awesome!
Reylo as endgame. So…Reylo kiss/ Reylo sex (don’t expect porn, you guys, a lot of great fanfic readers are very kindly providing that)… Probably off screen then (but a girl can dream on something tactful and romantic, the kids will be watching so obviously…)
TFA was Kylo and Rey fighting each other… TLJ is them fighting together. Episode IX should be them fighting for each other… You can’t convince me otherwise.
The MF… It has been key in the ST… Home… Bringing Ben home, or Rey and Ben leaving together at the end. Or Ben piloting the Falcon to do something important…
New saber for Rey… duh
A coup by Hux. Obviously. Rabid cur anyone? Division among the First Order.
Brace yourself: death of our heroes. One or the two of them. Litteral death of one of them, but the other resurrects it through love and use of the Force. Or symbolic death of one or the two of them, through imagery or suspense (we think they are dead but they are not). This is classic myth/fairy tale. It has to happen for them to complete their growth and journey. There is no other way around it. But it can happen many different ways… Don’t fret. I am expecting them to be alive and well at the end.
Balance of the Force… see the quotation from Journal of the Whills: grey Jedi.
Overarching theme for the saga and ST: “you win by saving what you love, not killing what you hate”/ Fairy tale morale/ Dante’s Divine Comedy… Need I say more?
What we can logically expect (as a continuation, or because they have hinted at it, or because that is what they do)
Porgs!!!! Anything with eggs, nesting… too many aviary and bird references in the ST movies and novelizations to overlook
Maz Kenata.. playing some part… or just a cameo. Or finally delivering some answer or advice…
Battles… with ships… in space. And on land… LOL
Leia’s death and/or funeral… Except if they recast her, but oh well… Han’s funeral was in the novelization for TLJ. We need a funeral anyways in the last installment. Padmé in the PT, Vader in the OT… We are bound to get a funeral in the ST. Leia seems like the logical choice. Multiple possibilities: fairly early on, and then you have Kylo trying to show up or sharing with Rey after it and it can play a part in bringing them together. Or at the end, and it is the funeral that brings the galaxy together and it helps everyone mourn their lost and loved ones. Padmé’s was the funeral that marked the end of unity, Leia’s could be the one that brings everyone together. With Rey and Kylo together behind the coffin, or putting a torch to the pyre, hand in hand, as chief mourners.
Tumblr media Tumblr media
Division in the Resistance? As a parallel to the First Order’s inner divisions? Would seem logical. I could see Poe struggle as a leader. Or Rey not being comfortable with everything about the Resistance, especially when it comes to Kylo. Rey still needs to figure out where she belongs… She belongs with Kylo. So, she might have issues finding her place in the Resistance. Just as he will not be happy with the First Order as seen by Hux.
Stormtrooper rising. They have focused more on the extra material about the human face of the Empire. See Claudia Gray’s Lost Stars, and the Junior novelization of TFA. Deleted scene of TLJ. Yes, Finn might not just be a bug in the system, it may be the first sign of more to come. Along with the division within the First Order, there may be stormtroopers rebelling and deciding between Kylo and Hux. Plus it gives Finn the chance to shine bright as the one who reaches out to dissident stormtroopers.
Tumblr media
Use of the Jedi texts: they can’t have been stolen for no reason.
More FinnRose.
Kylo as good leader/benevolent emperor.
A Force ghost. I wonder if we will get a ROTJ type of ending with all our ghosts gently beaming… Or if they will just pop in to comment Rey and/or Kylo’s actions. We had them in the OT obviously. Not so much in the PT where Qui-Gon could have made an appearance/apparition… It is actually weird he didn’t but maybe Liam Neeson was not interested, who knows?
Tumblr media
The ending should be on a lush planet. To symbolize rebirth, renewal, fertility, and the return to Paradise. And as a counterpoint to the ending of PT on Mustafar/Hell.
We might have the return of other known systems, Naboo or Mustafar, but I would really love to see Chandrila featured. It has been heavily featured in the extra material for the ST: in Last Shot, Leia Princess of Alderaan, and Aftermath series. We have seen Jakku, Rey’s birthplace, it would be logical and expected to see Chandrila, birthplace of Kylo. Also, don’t you think it eerily looks like Earth?
Tumblr media
A nod to Padmé is overdue. Poor Padmé. Her part was already butchered in the PT. She is vaguely alluded to in the OT… It would be nice to see her somewhere in the ST. Extra material has been alluding and hinting at her…
Someone finding about Rey and Kylo’s force bond and special relationship and being shocked. I am imagining Rose or Finn. Either they keep her secret but call her out on it. Or they betray her secret, for her own good as they see it, and that prompts Rey to dramatically choose to defend Kylo. I have a head canon on BB8 playing a part in all that (catching them during a meeting and playing the holo of their tryst, for example… LOL)
Tumblr media
Something that I desperately want to see but am unsure of… the overdue “I’ll come back for you sweetheart, I promise”, that is SO overdue and that is so important in the novelization of the movies, especially in the TLJ Junior version. I think I will pass out from excitement if I finally hear Kylo utter that line (which I deeply believe in).
Tumblr media
THAT scene from Rey’s Force vision in TFA. Because, WTF, JJ, you started that now you finish it!
Tumblr media
So possibly the elusive Knights of Ren?
Ok, I am sure I am forgetting some stuff. But, this is my piece for now. I hope that answers your questions. Please let me know your thoughts… Sorry it took so long! As for your question about completing it in one movie, well… @taule was telling me that she had heard people speculating they might make more… I would love it, of course, but they did say that ix was supposed to wrap up and tie in the whole Skywalker saga… Do not worry anyways,  because you can count on books, novels, comics, and animation to keep Kylo, Rey, and all their buddies alive and well for quite a while. I am predicting LOTS, TONS OF Kylo’s stuff once they are done with ix and can finally stop pretending about the redemption and survival of their character.
@raven-maiden, @toawaterfowl, @lightaroundthecorner My elves accepted to finally open one letter and get their act together to answer an anon that has been nice all year! LOL
441 notes · View notes
mcbex · 2 years
Text
**Worship, Warships & Shots Fired!**
Never give up. THIS IS A BATTLE. A campaign for our very souls and the crusade between good and evil always begins with a choice. The war is waged on us, in a desperate attempt to sever us from each other. We cannot forget we are family. I let my guard down for a second recently thinking that someone I love would talk to me about Jesus. I don't mind telling you, I am shaken. I've been a bit of a stirred mess about it. Not because a person isn't free to choose and be and think as they are, still assured to have my unconditional love. But because of how immensely I feel that they are missing something great. In an effort to sort through my feelings I've had many conversations this past week about Gods love and what it means to stand in Gods light as juxtaposed to Satan's shade. I've come to the conclusion that worship, prayer and enduring love is everything that keeps the battle from raging. I see the battle roar inside others as well who are anxious for the truth. It makes me ache, while I reach for real love. It makes me quiver because I have lived that life before and I know there is a better way.
After sometime stewing over this, I'm arguing with myself about it. I feel so small on this celestial planet. How do I approach this world in love? How do I stand firm in my countenance and help others reach, realize, react then...reach for others? Of course that's an answer that I will find as I continue to listen to the plans designed by the creator. Each piece doled out as needed until the quilt is complete. For my part all I can do is not loose faith. All I can do is become unwavering in my search for the truth. All I can do, is in every choice I make, choose the love I so badly want to give. In all this I still feel shaken. Which has caused me pause. I've become absorbed with where we begin, and how all of us affect each other. Beyond that, when I peel the layers back I see that we come together in a dance that makes the foundation of our purpose. I am in awe of the tapestry. I am in reverence of how we have no control over where we are stationed or even that we 'are' at all. I ask, why am I here. Not the deep "why is everything", kind of question, more like the "why this place, in this time" sort of query.
While riding the chairlift last week I saw a lot of wilderness on display. God really puts his master craftsmanship on parade if we take the time to look. However as I inspect the forest I think they might feel the same way I do. Questioning their purpose, maybe even asking God why they were planted where they stand. They have as much control as I did about when and where they would be born. Looking at exposed trees beside the lifts and trails I have to think they might wonder if the whole world is this way. Unaware of the beauty that lay just feet away inside the ample woods. Unaware of their part to play in this dance we share. Unaware that similar issues abound everywhere. They may have chosen something different for themselves if they had the choice. If they knew they'd find themselves on a gorgeous mountain side littered with people and electric comforts. Surely there is a quiet serene part of the forest they would find more comforting. But then what. What good would that do to be another sapling mixed amoung trees? That’s someone else’s place. Someone else’s reason, someone else’s purpose to help God. To reach and react in this beautiful heap. These other places have a whole set of different affairs to face. If we do pick up and move, if we change our scenery, if we move to a different plot of ground we will miss the view entirely. The course of action will still be useful but it will be plan B or C. We miss the uniquely shaped display that was made to make us who we are. We miss the juncture to become the people we are made to be or the chance to lead the way for those we love.
No, we must stay the course. Never giving up. The war is fought in so many ways on so many levels everywhere. In order to understand the battle, you gotta get on the destroyer. You've got to come to the conclusion that worship, prayer and enduring love is everything that keeps the battle from raging. After all I'm just waiting on heaven and Jesus never gave up on me.
1 Peter 5:8 Stay alert! Watch out for your great enemy, the devil. He prowls around like a roaring lion, looking for someone to devour.
Hebrews 12:14-15 Try to be at peace with everyone, and try to live a holy life, because no one will see the Lord without it. Guard against turning back from the grace of God.
1 Thessalonians 5:16-18Be joyful always,pray at all times, be thankful in all circumstances. This is what God wants from your life in union with Christ Jesus.
0 notes
suzanneshannon · 5 years
Text
How to Section Your HTML
It has been brought to our attention in the comments that some of the techniques used in this article result in a poor user experience for screen reader users. Daniel has updated the post accordingly with alternate markup in several of the examples and demos. We'll continue to make edits to address other things that others have noticed. Thanks for being such an awesome community where we can all learn and grow together.
The sectioning elements in HTML5 are <nav>, <aside>, <article>, and <section>. <body> is also kind of a sectioning element since all content lying inside of it is part of the default document section.
Here is a brief explanation of each sectioning element and how they are used:
<nav> - Equivalent to role="navigation". Major site navigation that consistently appears frequently across the site. Examples include the primary navigation, secondary navigation, and in-page navigation.
<aside> - Equivalent to role="complementary". Content that is only tangentially related (or not related) to the main content. Think of something like a sidebar with supplementary information, a note within an article, or the outer container for a list of related articles at the bottom of a blog post.
<article> - Equivalent to role="article". Content that is self-contained in that it makes sense on its own when taken out of context. That could mean a widget, a blog post or even a comment within a blog post.
<section> - Equivalent to role="region". Content that needs extra context from its parent sectioning element to make sense. This is a generic sectioning element that is used whenever it doesn’t make sense to use the other more semantic ones.
https://t.co/NAZMrlQ1O5
I added HTML comments with some explanation of changes I made.
— Adrian Roselli 🗯 (@aardrian) June 20, 2019
See the Pen Mock up page layout v2 (sections article) by Adrian Roselli (@aardrian) on CodePen.
Contents
This is a very long article that I suspect you will want to come back to and reference multiple times. To make that easier, here is a list of all the article headings:
Jump to article heading
When to use <nav>
A <nav> is unnecessary around a search form
Don’t use the word "nav" or "navigation" in the label
Questions to ask yourself
A <nav> doesn’t have to be a list of links
Avoid nesting an <aside> inside an <aside>
Article is like "Block"; Section is like "Element"
Comments sections
Don’t swap <div> for <section>
Headers and footers
What goes inside headers?
What goes inside footers?
Sectioning elements and the document outline algorithm
No browser supports the document outline algorithm
Sectioning content
The <main> element
You need to label your sections. Here are three methods.
Method 1: Add an aria-label attribute
The aria-label translation issue
Positives
Negatives
Method 2: Add a <h#> element to it
Heading placement
Only one heading of the highest level per sectioning element
The heading always comes first
Making visually hidden section labels out of headings
Headings are well-supported by structure analysis tools
Positives
Negatives
Method 3: Use an aria-labelledby attribute
Labels can be hidden without CSS
Major portability issue
No need to place the label near the sectioning element
Turn non-heading elements into section labels
Positives
Negatives
Only use one method at a time
Adding section labels to our example layout
Making Heading 1 be the first heading
Concerns with the simplified outline algorithm spec
Using aria on the example layout sectioning elements
Using aria-label
Using aria-labelledby
Results of using aria
What happens when you need h7?
Does your site have a good structure?
Download and use a screen reader
When to use <nav>
The <nav> element only ever needs to be used once per navigation block. Sub-navigation that is already contained inside a <nav> element does not need to be wrapped in a second <nav> element.
<nav aria-label="Primary"> <ul> <li><a href="#">Primary link</a></li> <li><a href="#">Primary link</a></li> <li> <a href="#">Primary link</a> <!-- <nav> element is *not* needed again here --> <ul> <li><a href="#">Secondary link</a></li> <li><a href="#">Secondary link</a></li> </ul> </li> </ul> </nav>
The <nav> element is intended for only major navigation blocks. "Major" is a very subjective term though. html5doctor.com has a pretty good explanation of when it is and isn’t appropriate to use <nav>, keep in mind that the following are opinions and not official W3C rulings:
The key phrase is ‘major’ navigation. We could debate all day about the definition of ‘major’, but to me it means:
Primary navigation
Site search
Secondary navigation (arguably)
In-page navigation (within a long article, for example)
While there isn’t any right or wrong here, a straw poll coupled with my own interpretation tells me that the following shouldn’t be enclosed by <nav>:
Pagination controls
Social links (although there may be exceptions where social links are the major navigation, in sites like About me or Flavours, for example)
Tags on a blog post
Categories on a blog post
Tertiary navigation
Fat footers
— html5doctor.com (strikethrough mine)
Breadcrumbs are another piece of content that should be wrapped in a <nav> element as evidenced by this W3C breadcrumb HTML example.
A <nav> is unnecessary around a search form
I disagree with HTML5 Doctor’s opinion that a site search form should be wrapped in a <nav> element (thus why I crossed it out). <nav> is intended to be wrapped around navigation links, not a form. The site search actually has its own special role that defines it as a search landmark. If you add role="search" to the search <form> element, it is announced to screen reader users as a search landmark. Screen reader users will also be able to navigate to it when navigating via landmarks. If there are multiple search forms on the page, they should be differentiated using aria-label or aria-labelledby (more details on these attributes later). Don’t include the word "search" in the aria label though — that’s like saying "image of" in image alt text; it’s unnecessary. Instead, focus on what the search form is searching through. So, for the global site search, giving it aria-label="site" would be appropriate.
<!-- <nav> is not needed on a search form. --> <!-- role="search" is enough --> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search" /> </label> <buton type="submit">Submit</button> </form>
A role="search" form won’t appear in a document outline but I think this is okay considering search forms are often small and self-contained. It still gets the majority of benefits that you get from using sectioning elements. Adding a sectioning element to the mix bombards the screen reader user with messages telling them that it is a search form (one for the sectioning element, one for the search role, and one for the search input label).
Don’t use the word "nav" or "navigation" in the label
Like with role="search", adding "navigation" to the label of a <nav> element only results in a screen reader saying "navigation" twice.
<nav aria-label="primary navigation"> <!-- Screen reader: "primary navigation navigation landmark" --> </nav> <nav aria-label="primary"> <!-- Screen reader: "primary navigation landmark" --> </nav>
Questions to ask yourself
That same HTML5 Doctor article lists two questions that you can ask yourself to help you figure out if something should be wrapped in a <nav> or not:
Would another sectioning element also be appropriate? If yes, maybe use that instead.
Would you add a link to it in a "skip to" block for accessibility? If not, then it might not be worth using a <nav> element.
In those cases where the navigation is too minor to justify the use of the <nav> element, <section> is most likely the element that you should use instead.
A <nav> doesn’t have to be a list of links
The most common use case for a <nav> is to wrap it around a list of links but it doesn’t have to be a list of links. If your navigation works in a different sort of way, you can still use the <nav> element.
<!-- Example taken from the <nav> element specification --> <!-- https://html.spec.whatwg.org/multipage/sections.html#the-nav-element:the-nav-element-5 --> <nav> <h1>Navigation</h1> <p>You are on my home page. To the north lies <a href="/blog">my blog</a>, from whence the sounds of battle can be heard. To the east you can see a large mountain, upon which many <a href="/school">school papers</a> are littered. Far up thus mountain you can spy a little figure who appears to be me, desperately scribbling a <a href="/school/thesis">thesis</a>.</p> <p>To the west are several exits. One fun-looking exit is labeled <a href="https://games.example.com/">"games"</a>. Another more boring-looking exit is labeled <a href="https://isp.example.net/">ISP™</a>.</p> <p>To the south lies a dark and dank <a href="/about">contacts page</a>. Cobwebs cover its disused entrance, and at one point you see a rat run quickly out of the page.</p> </nav>
In this same vein, it’s okay to have small bits like intro text in the <nav> element as long as the primary focus of the content is on the navigation links. Introductory content is best placed inside a <header> in the <nav> element. I’ll go into more depth on headers and footers later.
<nav> <header> <h2>In this section</h2> <p>This is some intro text describing what you will find in this section.</p> </header> <ul> <li><a href="#">Sub section one</a></li> <li><a href="#">Sub section two</a></li> </ul> </nav>
Avoid nesting an <aside> inside an <aside>
In the same way that <nav> shouldn’t really ever be nested inside another <nav> element, <aside> elements also tend not to be nested inside each other. <aside> is used to represent content that is tangentially related to the content around it. That means placing an aside inside an aside is basically announcing a tangent away from something that in itself is a tangent away from the main content.
<!-- Don't do this --> <aside aria-label="Side bar"> <aside> <h2>Share</h2> <ul> <!-- List of social media links --> </ul> </aside> <aside> <h2>Recommendations:</h2> <ul> <li> <article> <h2><a href="#">Related article title</a></h2> <p>Article description</p> </article> </li> <!-- List of recommended articles continues --> </ul> </aside> </aside>
If you have a sidebar that has multiple sections, don’t nest <aside> elements inside of <aside> elements like in the example above. Instead, make the sidebar a single <aside> and then use <section> (or another appropriate sectioning element) to create the different sections.
<!-- Do this instead --> <aside aria-label="Side bar"> <section> <h2>Share</h2> <ul> <!-- List of social media links --> </ul> </section> <section> <h2>Recommended articles:</h2> <ul> <li> <article> <h2><a href="#">Related article title</a></h2> <p>Article description</p> </article> </li> <!-- List of recommended articles continues --> </ul> </section> </aside>
Article is like "Block"; Section is like "Element"
<section> and <article> are easy to get confused with one another. If you are familiar with "Block Element Modifier" (BEM) syntax, then an easy way to think of the difference between the two is that an <article> is a bit like the "B" (or "Block") in BEM. It is a container that stores self-contained content that still makes sense when placed in a different context. Individual tweets on Twitter and each list item on a search results page would be considered <article> elements.
<section> is like the "E" (or "Element") in BEM. It is a sub-section that requires context from its parent sectioning element to make sense. <section> is a generic catch-all sectioning element that you use when it doesn’t make sense to use the other sectioning elements. So, if in doubt, go with <section>.
Note that if something is styled as a "Block" in BEM, that doesn't automatically mean that it is an <article> element. Same goes for BEM "Elements" and <section> elements. The element of something should be based on the meaning of the content, not how the content looks.
Comments sections
Something that may surprise people is that individual comments on a blog post are also considered articles, even though they are in reply to the main blog post. The <article> element wrapping around the main blog post should also wrap around the comments section though. This is to represent that the comments go with the main article.
<article> <h1>I am an awesome blog post!</h1> <p>I am some body text content.</p> <section> <h2>Comments</h2> <ul> <li> <article> <h2>Username</h2> <p>This is the comment body text.</p> <footer> <p> Meta data like post date makes sense in either the header or the footer. </p> </footer> </article> </li> </ul> </section> </article>
Don’t swap div for a section
Just because we have these fancy sectioning elements now, it doesn’t mean that the good old <div> element has lost all of its usefulness. <div> has no semantic meaning, so it is quite useful whenever we are altering the HTML purely for the sake of styling purposes.
Let’s say that we have a blog post contained inside an <article> element that we need to wrap in something for the sake of styling purposes.
<!-- I need a wrapper element --> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article>
Reaching for the <section> element in this circumstance is not the right thing to do.
<!-- Do not do this --> <section class="wrapper"> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article> </section>
Though <section> is technically a generic element, <div> is the far more appropriate option in this circumstance. This new wrapping container is not meant to have any semantic meaning behind it and that is exactly what <div> is designed to be used for.
<!-- Use a <div> if the element is only used for styling purposes --> <div class="wrapper"> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article> </div>
Another way to remember this: if you can’t think of a meaningful heading to apply to a <section>, then it probably shouldn’t be a <section>.
Headers and footers
Although they don’t necessarily need to, sectioning elements may contain a single <header> and a single <footer> with the header being at the top of the section and the footer being at the bottom.
Sectioning elements can be nested inside one another as many times as is needed based on the content.
The header and footer in a sectioning element can also contain sectioning elements.
The one major restriction around nesting sectioning elements is that headers and footers cannot be nested inside other headers and footers.
Nesting headers and footers inside one another is not allowed.
What goes inside headers?
Headers are used for introductory content. Appropriate things to include in <header> elements include (but are not limited to):
The heading element (<h1>-<h6>)
An introductory paragraph or statement.
A profile picture
A logo
A search form
Primary navigation
Author’s name
Post/updated date
Meta data
Social media links
What goes inside footers?
Footer elements primarily hold things like meta data and minor supporting content. Appropriate things to include in <footer> elements include (but are not limited to):
Copyright information
Legalities
Footnotes
Low priority site navigation
Author’s name
Post/updated date
Meta data
Social media links
You will notice that there is some cross over between the header and the footer in terms of content that is appropriate to both. This is mostly because meta-type content fits well in either element. It mainly comes down to the design that you are trying to achieve. <header> elements do tend to signify that the content inside of them is of greater importance than the content inside of a <footer> element though.
Sectioning elements and the document outline algorithm
An important thing to know about these sectioning elements is that they are all supposed to feature a <h#> element inside of them (or be labeled in some other way, but more on that later). This is primarily for the sake of something called the document outline algorithm. This is an algorithm that uses sectioning elements to help determine what level a heading (<h#>) should be without having to rely exclusively on the number that the developer has provided. So, have you ever wondered whether or not it’s okay to have more than one <h1> on a page? This is meant to make that a non-issue (but hold on for a sec, because there is more to the story).
<!-- No Document outline algorithm --> <article> <h1>Primary heading</h1> <h2>Secondary heading</h2> <p>Some text.</p> <h3>Tertiary heading</h3> <p>Some text.</p> </article>
<!-- With document outline algorithm --> <article> <h1>Primary heading</h1> <!-- Recognized as <h1> --> <!-- sectioning element sets new heading level context --> <section> <h1>Secondary heading</h1> <!-- Recognized as <h2> --> <p>Some text.</p> <h2>Tertiary heading</h2> <!-- Recognized as <h3> --> <p>Some text.</p> </section> </article>
There is a lot more to learn about the document outline algorithm. I’ll stop here though because...
No browser supports the document outline algorithm
There is not a single browser that supports this method of creating a heading structure. This is a shame. It would make building accessible websites much easier if we didn’t have to worry so much about using the correct heading level all the time.
As far as I’m aware, there are two main reasons why no browser has implemented the algorithm. One is that browser vendors are afraid of breaking the heading structure of sites that have used sectioning elements incorrectly. The other reason is that the current document outline algorithm spec is difficult to implement and no browser vendor has been willing to put the time into implementing it yet.
In reference to the first reason, there is a long discussion about incorporating a new <h> element instead of using the <h1> element to tell browsers to use the document outline algorithm. I was in favor of this new <h> element idea until I realized that an attribute on the <html> element or adding a <meta> tag to the <head> would work even better as a means of telling browsers it was safe to use the algorithm. It is also better for headings to fall back to a <h1> in unsupported browsers than falling back to a <span>.
If you would like to play around with this <h> concept though, there is a plugin called hfill. It allows you to nest <hx> headings inside sectioning elements to create the document outline without having to worry about heading levels so much. There is a demo available for you to try it out. The major flaw in this plugin though is that the only way to increment heading levels is by nesting sectioning elements inside one another. There is no <h1>-is-greater-than-<h2> dynamic in this plugin which is the main reason I fell out of love with this <h> element idea. This lack of heading hierarchy would make CMS rich text editors far too difficult for clients to use.
As for the issue around implementation difficulty, work is being done to produce a simplified spec that browser vendors are more likely to adopt. The document outline algorithm has been in the HTML specifications for years. Hopefully this simplified spec will allow the algorithm to become a reality.
Although the algorithm is not supported anywhere yet, we can still build with the algorithm in mind. If we build with it in mind, then we gain the following benefits:
We future-proof our sites in case the algorithm ever does get implemented.
We can significantly improve the user experience for screen reader users.
We potentially improve search engine optimization (SEO) due to search engines being able to better understand the site’s content.
We can create a better user experience for users by allowing them to use native browser features that make use of sectioning elements, like Reader Mode.
Sectioning content
Take a look at this mock-up layout I put together and think about how you might split it up into sections.
This is how I would split the layout up into sectioning elements (only the solid lines represent sectioning elements).
In terms of HTML markup, it looks like this:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
The <main> element
There is a very important semantic element that I used in the markup above that I haven’t covered yet and that is the <main> element. The <main> element represents the primary content of the page. It is not supposed to feature any side bars or navigation elements in it. You also must not have more than one <main> element on the page unless all other <main> elements on the page have a hidden attribute applied to them (this is for the sake of SPAs).
The <main> element is not a sectioning element. This means that it doesn’t help contribute to the document outline algorithm and it can’t feature a <header> or <footer> element as a direct child. It is a landmark element though so screen reader users are able to navigate to it quite easily.
I’m not 100% sure if using <article> in the <main> element like I have done above is necessary. Semantically, it does make sense. The main content is self-contained, thus justifying use of the <article> element in this way. From a document outline algorithm perspective, the <article> element also helps with the document structure.
From a usability point of view, it feels a bit unnecessary and the document outline algorithm doesn’t even work anywhere at the moment. I’m going to continue using it throughout my examples but I would be interested to know what other people think about this in the comments section.
You need to label your sections. Here are three methods.
I am going to be saying the word "label" a lot throughout this article. Keep in mind that I am not talking about the <label> element. The <label> element is not used to label sectioning elements.
Sectioning elements require labels so that screen reader users are able to quickly identify what content they can find inside that particular section of the site. I consider using sectioning elements without providing associated section labels as an accessibility fail, unless it is the only one of its type on the page. It is also recommended that the exact same label text not be used on multiple sectioning elements (or heading elements). This makes each section more recognizable to screen reader users which helps them navigate the site more easily.
There are three ways to label a sectioning element. In the following examples, I refer to "transport" and "portability" as a way of explaining how easy it is to save the section into a component and use that component multiple times in multiple different contexts.
I also provide lists of positives and negatives in the examples as well. In these lists, I assume that you want the section label to be readable by screen readers but hidden from sighted users.
Method 1: Add an aria-label attribute
This is the quickest and easiest way to label a sectioning element.
<section aria-label="Label for this section"> <p>Content for this section</p> </section>
#The aria-label translation issue
The main draw back of aria-label (at the time of writing) is that most browsers are unable to translate these values for users who speak a different language than you. The developers at Google recently fixed this bug in Chrome, however this is still a problem for every other browser.
If your website has a large international audience or you know that many of your users do not speak your language, you should probably avoid using this attribute until all browsers support the translation of this property. If you don’t have those sorts of users, it’s pretty safe to assume that the non-sighted users viewing your site are able to understand your language — well enough to be able to navigate your site, anyway.
If you need more convincing, let's say your site has very few international users. That means your users generally come from the same country as you. If they come from the same country then they are likely to speak the same language as you, so there is already a fairly small percentage of your users that don’t understand the native language of your site. Now take into account that aria-label only affects screen reader users. That is now only a fraction of an already small percentage of your users who will experience the issue. And now consider that Chrome (by far the most popular browser in the world) now supports translation of the aria-label attribute. The user has to also not be using an up to date version of Chrome as their browser for the translation issue to be a problem. If you factor all of that together, it is highly probable that you may not have any users who are both able to perceive the aria-label attributes and are incapable of comprehending what they say. This makes me feel like the bad multi-lingual support in aria-label isn’t really worth worrying that much about unless you have a large international audience or you have many users that you know do not speak your language.
#Positives
Super quick and easy to implement.
Doesn’t affect heading structure.
Makes components easy to transport.
Is invisible to sighted users.
#Negatives
Not translated into other languages in non-Chrome browsers (at time of writing).
Often not supported by page structure analysis tools.
Confusion can arise from not knowing what level other headings inside the section should be at.
Method 2: Add a <h#> element to it
By <h#> I mean <h1>, <h2>, <h3>,<h4>,<h5>, or <h6> depending on what makes sense. Adding a heading to a sectioning element is a quick way to label it.
#Heading placement
The heading can be placed either directly in the sectioning element, like this:
<section> <h1>Heading</h1> <p>content</p> </section>
...or placed inside the <header> element:
<section> <header> <h1>Heading</h1> <p>I'm a byline</p> </header> <p>Content</p> </section>
You can also place as many <div> wrapper elements between the sectioning element and the heading as you want.
<!-- This is perfectly fine --> <section> <div> <header> <div> <h1>Heading</h1> <p>I'm a byline</p> </div> </header> <p>Content</p> </div> </section>
#Only one heading of the highest level per sectioning element
There should really only be one heading of the highest level in a sectioning element. The spec says that when there are multiple top level headings or headings of a higher level than the first, the browser is supposed to close the previous sectioning element and start a new one of the same type.
The first element of heading content in an element of sectioning content represents the heading for that explicit section. Subsequent headings of equal or higher rank start new implied subsections that are part of the previous section’s parent section. Subsequent headings of lower rank start new implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.
—HTML 5.3, Headings and Sections
In reality, the browser uses the first heading as the section label but these implied sections are never created. It just announces the heading as is when it encounters it. It’s not earth-shatteringly bad but it is somewhat confusing.
<!-- Avoid this: --> <section> <h2>Heading level two labeling a section</h2> <p>Content</p> <!-- Don't use same level or higher headings as the one labeling the section --> <h2>This is also a heading level two</h2> <p>Content</p> </section> <!-- Do this instead: --> <div> <section> <h2>Heading level two labeling a section</h2> <p>Content</p> </section> <section> <h2>Heading level two labeling a different section</h2> <p>Content</p> </section> </div>
#The heading always comes first
If a sectioning element has a <h#> element, that top level heading should always be the very first piece of content inside that sectioning element. Failing to do so counts as an accessibility fail.
If you find yourself needing to place content before your heading (like an image, for example), you can use Flexbox to rearrange the visual order. This will allow it to look like the image comes before the heading but in the markup the heading comes before the image. There is a bug in IE that will sometimes cause text to not wrap in a flex-direction: column; element. You can work around this issue by applying a max-width to the flex-child element.
<!-- Don't do this --> <section> <img src="image.jpg" alt="Don't place content or images before the heading" /> <h2>Headings should always come first</h2> <p>Place regular content after the heading</p> </section> <!-- Do this instead --> <section class="example"> <h2>Headings should always come first</h2> <img src="image.jpg" alt="Don't place content or images before the heading" /> <p>Place regular content after the heading</p> </section> <style> .example { display: flex; flex-direction: column; } .example img { order: -1; } </style>
Note that rearranging the visual order to satisfy WCAG Guideline 1.3.2: Meaningful Sequence can conflict directly with WCAG Guideline 2.4.3: Focus Order. For example, if that image is a link to an article and the heading you are placing it above is also a link to the article, placing the heading first breaks the focus order. Placing the image first breaks the meaningful sequence.
In situations like this where these two guidelines conflict with one another, my opinion is that the 1.3.2: Meaningful Sequence guideline is the more important guideline to follow if you aren’t able to resolve the conflict in some way. Failing focus order leads to the user suffering a moment of discomfort as they are tabbing through the content and focus is sent to an unexpected location. Failing to follow a meaningful sequence leads to a confused user unsure of the relationship between different bits of content.
#Making visually hidden section labels out of headings
Headings are visible to sighted users by default. This makes them super useful if you want the heading to be visible. A lot of the time, we don’t want the label for our sectioning element to be visible though. In order to stop our sighted users from seeing the label, we need to use some CSS.
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <section> <h1 class="visually-hidden">Heading</h1> <p>content</p> </section>
#Headings are well-supported by structure analysis tools
Headings also have a huge advantage for developers in that any page structure analysis tool that you can find will have support for them. This makes heading structures easy to test and debug. The other two section labeling methods have very poor support in testing tools. Not even the official W3C Validator service supports the alternatives at the moment. I posted an issue to have this fixed — please consider helping to fix the issue if you are good at coding in Java.
#Positives
Quick to implement.
Reliably appears in page structure analysis tools making it easy to test and debug.
All browsers will translate the text into other languages.
No confusion over what level other headings inside the section should be.
#Negatives
Affects document heading structure.
Need to ensure that the heading is at the correct level before use.
Visible to the user by default.
Requires CSS to hide the heading from visual users.
Can make components less portable due to heading structure requirements.
Method 3: Use an aria-labelledby attribute
This is what it looks like to create a hidden section label using aria-labelledby.
<section aria-labelledby="unique-id"> <div hidden id="unique-id">Label for this section</div> <p>Content for this section</p> </section>
#Labels can be hidden without CSS
Note that I used the hidden attribute in the example to hide the div rather than a visually-hidden CSS class. aria-labelledby is able to read out text that is normally hidden from screen reader users. This adds the bonus effect of preventing the text from being read out twice by the screen reader. Don’t use the aria-hidden attribute though. Screen readers will not find the label text. Well, NVDA couldn’t find the label text when I tested it. I’m not sure about other screen readers.
#Major portability issue
aria-labelledby is the most difficult to use out of all the section labeling methods. The main aspect that makes it difficult to use is that the aria-labelledby attribute works off IDs. Things always get more complicated whenever IDs are involved. This is due to web pages only being allowed to have a single instance of an ID on the page at any one time. This makes component portability difficult.
Due to this portability issue, I would really only recommend this option if you need to support a multi-lingual audience and don’t want to mess around with the heading structure.
#No need to place the label near the sectioning element
You don’t need to place the element with the label text inside or near the section element that it labels. The text for the label can be placed in a completely different location to the sectioning element. This is thanks to the ID linking the two elements together. I’m not necessarily saying that it is a good idea to do this, but it is a feature of aria-labelledby that you should be aware of.
<div hidden id="unique-id">Label for this section</div> <!-- 1,000 lines of other HTML --> <section aria-labelledby="unique-id"> <p>Content for this section</p> </section>
#Turn non-heading elements into section labels
There is one other key reason you may want to use aria-labelledby. If you have a visible non-heading element on the page that you want to use as the label for a section, aria-labelledby is perfect for this. A <legend> element inside a <fieldset> is a common use case for this. This doesn’t mean that you have to wrap fieldsets in sectioning elements. I’m just pointing it out in case you spot a need for it.
<section aria-labelledby="section_label"> <fieldset> <legend id="section_label"> I am both the fieldset legend and the section label </legend> <!-- Form fields go here --> </fieldset> </section>
#Positives
All browsers will translate the text into other languages.
Can assign a non-heading element as the section label.
Text for the label does not need to be placed near the section it is labeling.
#Negatives
Requires the use of IDs to work.
Difficult to transport.
It can potentially be difficult to track down where the text for the label is stored in your source code.
Text is visible by default unless a hidden attribute is used.
Text might get read out twice by some screen readers if the text is not hidden.
Confusion can arise from not knowing what level other headings inside the section should be at.
Only use one method at a time
Don’t use a <h#>, an aria-label and/or an aria-labelledby attribute at the same time on the same sectioning element. Only every use one labeling method at a time for each sectioning element. Using multiple methods is super confusing and leads to the label being overwritten. It’s a bit like declaring the same property twice in CSS. I wasn’t sure how a screen reader would actually handle this so I created the most ridiculous <section> ever and ran it through NVDA.
<!-- Don't do this --> <section aria-label="Is this the section label?" aria-labelledby="is_this_the_label"> <h1>Or is this the section label?</h1> <p id="is_this_the_label">Only ever use one at a time.</p> </section>
This is the order of priority that NVDA gave to the various labeling methods from strongest to weakest:
aria-labelledby
aria-label
<h#>
Adding section labels to our example layout
For a long time, I used headings as the only means of labeling sections. The poor multi-lingual support provided by aria-label scared me; and aria-labelledby was far too cumbersome to be my primary labeling method. We run into a bit of an issue though if we use only headings to label sections. I’ll show you what I mean.
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <h2 class="visually-hidden">Primary</h2> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <h2 class="visually-hidden">Secondary</h2> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <h2 class="visually-hidden">Sidebar</h2> <section> <h3>Share</h3> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h3>Recommended</h3> <ul> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
If we look at our heading structure now, it will look like this (italics = visually hidden; bold = visible):
li.no-list-dot::before { display: none; }
<h2> Primary [nav]
<h2> Secondary [nav]
<h1> Main article heading
<h2> Article secondary heading
<h2> Sidebar
<h3> Share
<h3> Recommended
<h4> Related article
<h4> Related article
Notice that our <h1> heading isn’t at the top of the list? It really doesn’t feel right having two <h2> headings above the <h1> heading.
This form of heading structure is actually allowed by the W3C so it doesn’t count as an accessibility fail. I still think that this is a pretty bad UX for screen reader users though. It is not a logical progression from <h1> to <h2>. It makes the most sense if the first heading you encounter on the page is a <h1> then progress into <h2> then <h3> and so on.
Making Heading 1 be the first heading
For a very long time, I thought the absolute best way to handle this conundrum was to make the <h1> visually hidden and have it be the very first piece of content on the page. The thing that everyone thinks is the <h1> actually becomes a <h2>.
This is what that sort of structure looks like in practice:
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <!-- Don't do this --> <body> <header> <h1 class="visually-hidden">Main article heading</h1> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <h2 class="visually-hidden">Primary</h2> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <h2 class="visually-hidden">Secondary</h2> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h2><span class="visually-hidden">Body:</span> Main article heading</h2> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h3>Article secondary heading</h3> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <h2 class="visually-hidden">Sidebar</h2> <section> <h3>Share</h3> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h3>Recommended</h3> <ul> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Now we have a document outline that looks like this (italics = visually hidden; bold = visible):
<h1> Main article heading
<h2> Primary [nav]
<h2> Secondary [nav]
<h2> Body: Main article heading
<h3> Article secondary heading
<h2> Sidebar
<h3> Share
<h3> Recommended
<h4> Related article
<h4> Related article
This mostly feels right. The <h1> is at the top and it all flows down perfectly with the <h2> elements representing major page sections and the <h3> elements representing sub sections. The main awkward bit is that the actual <h1> and the thing that everyone thinks is a <h1> are essentially duplicates of one another.
It wasn’t until I wrote up the first version of this article, had it nearly published, then had it thrown out the window, that I started to think differently. I talked with two accessibility consultants about the issue. They both agreed that, though this is a clever technical solution to the problem, it detracts from the experience of the very people that it is trying to help.
The issue is that when every other website in the world places the <h1> heading at the top of the main content area, that is what screen reader users come to expect. When your site is the special snowflake that does things differently, it confuses screen reader users and it takes them some time to figure out how your heading structure is supposed to work.
So, with that in mind, I’ve settled on a new method for handling the labeling of sectioning elements. Basically, any time I would have used a visually hidden heading, I would use an aria-label attribute now instead. If the site has a large non-native speaking audience, I would use aria-labelledby instead of aria-label.
Concerns with the simplified outline algorithm spec
If the simplified outline algorithm is approved in its current state, we will actually need to start structuring our sites like the visually hidden <h1> example anyway (just replace the <h2>, <h3> and <h4> elements with <h1> elements).
The original spec aimed to create the outline through the labeling of sectioning elements. This new spec is clearly aimed at trying to create the outline purely through heading levels. The algorithm basically calculates the heading level based on the number of ancestor sectioning elements a heading has plus the heading’s base heading level value. It's a bit more nuanced than that in the spec, but that is the general idea of how it works in simple terms.
The simplified algorithm currently makes no mention of aria-label or aria-labelledby. This means that those attributes will not help contribute to the document outline that the simplified algorithm generates. With a lack of aria-label support, this would mean labeling a sectioning element with aria-label could easily lead to skipped heading levels deeper in the tree.
<!-- Simplified algorithm skipped heading levels issue --> <body> <main> <h1>Primary heading for the page</h1> <!-- interpreted as <h1> --> <p>This is some content</p> </main> <!-- sectioning elements increase heading levels --> <aside aria-label="Side bar"> <!-- aria-label does not contribute --> <section> <h1>Share</h1> <!-- interpreted as <h3> --> <ul> <!-- list of social media links --> </ul> </section> <section> <h1>Recommended articles:</h1> <!-- interpreted as <h3> --> <ul> <!-- list of recommended articles --> </ul> </section> </aside> </body>
The simplified spec also considers it invalid to:
not have a heading level of 1 at the root of the document (which is problematic if you are placing the main body content inside an <article> element); and
not have a heading level of 1 be the first heading in a document (which, for the most part, is okay, unless you need to use a heading in the site header or in a left side bar).
It does, however, allow for there to be more than one level 1 heading at the root of the document, which I find very odd and bad for accessibility (though my concern about this seems to have been ignored).
I have voiced the issues I have with the spec and proposed possible solutions in the GitHub discussion.
For the moment, it is still best to use aria-label and/or aria-labelledby attributes instead of visually hidden headings to label sectioning elements. It isn’t worth diminishing the experience of our present day users for the sake of a spec that hasn’t even been finalized or accepted yet.
Using aria on the example layout sectioning elements
Using aria-label
This is what the HTML structure looks like if we use aria-label attributes to label the sectioning elements:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav aria-label="Primary"> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav aria-label="Secondary"> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside aria-label="Sidebar"> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Here is the layout in CodePen in case you want to have a play around with it (sorry mobile users, it's not mobile friendly):
See the Pen Mock up page layout v2 (sections article) by Daniel Tonon (@daniel-tonon) on CodePen.
Using aria-labelledby
But let’s assume that you have a huge international audience that speaks all sorts of languages. In that case, it is better to use the aria-labelledby attribute. Here is what that would look like:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav aria-labelledby="primary-nav-label"> <div id="primary-nav-label" hidden>Primary</div> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-labelledby="search-label"> <div id="search-label" hidden>Site</div> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav aria-labelledby="secondary-nav-label"> <div id="secondary-nav-label" hidden>Secondary</div> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside aria-labelledby="sidebar-label"> <div id="sidebar-label" hidden>Sidebar</div> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Results of using aria
The heading structure for the site at this point looks like this:
<h1> Main article heading
<h2> Article secondary heading
<h2> Share
<h2> Recommended
<h3> Related article
<h3> Related article
The document outline (assuming that the original outline algorithm is implemented) looks like this:
<body> Document
<nav> Primary
<nav> Secondary
<article> Main article heading
<section (implied)> Article secondary heading
<aside> Sidebar
<section> Share
<section> Recommended
<article> Related article
<article> Related article
You might be thinking that the document outline looks a bit bare. Shouldn’t things like the header and footer and search be announced in there as well? Keep in mind that this is just the explicit stuff. We get a lot of implicit information provided to the user for free by using correct HTML elements in a good structure. This is a simplified version of how a screen reader user might experience the site:
[Text used in the <title> element]
Banner landmark
Link, site logo [(on focus) "go to home page"]
"Primary" navigation landmark
[List of navigation links]
"Site" search landmark
"Secondary" navigation landmark
[List of navigation links]
Main landmark
"Main article heading" article landmark, heading level 1
[Content]
Heading level 2, "Article secondary heading"
[Content]
"Sidebar" complimentary landmark
"Share" region landmark, heading level 2
[List of share links]
"Recommended" region landmark, heading level 2
List with 2 items
Item, "Related article" article landmark, heading level 3
[Content]
Item, "Related article" article landmark, heading level 3
[Content]
Content info landmark
[List of footer links]
As you can see, the site structure becomes quite clear and understandable to screen reader users when you factor in all of the extra implicit information that you get from using a good HTML structure
So, even though no browser supports the document outline algorithm, it is still worth putting some effort into thinking about the outline. Screen readers still tell users what type of section something is, where sections start and (sometimes) end (depends on the screen reader), and what the section label is. This means that your efforts to make a good document structure do not go to waste.
This type of structure comes with multiple benefits:
The page is 100% compatible with the document outline algorithm, future proofing it in-case the algorithm is ever implemented in a real browser.
The heading structure is completely logical.
Screen reader users navigating via headings can quickly jump to important information.
Screen reader users navigating via landmarks have lots of useful landmarks to move about the page.
Screen reader users are able to quickly understand what each section contains without having to read any of the content inside of them.
Content is grouped into semantic sections, so screen reader users do not get confused when leaving one section and entering another.
Search engines are able to better understand what information each section holds, which could potentially improve SEO.
Sighted users can take advantage of native browser features like Reader Mode.
What happens when you need h7?
There is one more sticking point when it comes to labeling sectioning elements that I haven’t addressed yet. Let’s say you have somehow managed to use up all six native heading levels and are now stuck needing one more. What do you do?
You could use the aria-labelledby technique if it is just for the sake of labeling a section. Let’s say that you really want this heading to appear in the heading structure though, or maybe you just want to avoid using IDs as much as possible. Whatever the reason, you need an <h7> element but <h7> doesn’t exist.
This is when the aria-level attribute comes to the rescue. The aria-level attribute will define what the heading level should be for elements that have role="heading" applied to them. This is how the W3C recommend creating a <h7> element:
<div role="heading" aria-level="7">This is a valid heading level 7 element</div>
Not all screen readers support this syntax. I know that JAWS treats these like <h2> elements rather than <h7> elements. If you know of any screen readers that this doesn’t work in, please report the bug to the screen reader developer and also leave a comment down below.
When I need to reach for an <h7>, I’ll often use the implied role="heading" from an <h6> element instead. The aria-level attribute will override the implicit "6" level of the <h6> element. This isn’t exactly endorsed by the W3C though. It is cleaner and will allow the heading to still appear in document outline and heading structure testing tools (though they will typically appear as <h6> or <h2> level headings, not as <h7> level headings).
<h6 aria-level="7">This is also a valid heading level 7 element</h6>
By using aria-level, you now have access to an infinite number of heading levels!
Does your site have a good structure?
Now that you know how to do a proper HTML structure, are you able to apply what you have learned to your website?
I found a pretty good browser extension called "Headings Map" that is available for both Chrome and Firefox. This extension will allow you to easily see both a flat heading structure representation of your site (i.e. how all browsers currently read the heading structure) and what the document structure looks like in a browser that supports the document outline algorithm (i.e. how a theoretical future browser that supports the outline algorithm would present the site structure). The HTML5 Outline view needs to be enabled in the settings menu first. This is to prevent users from being fooled into thinking that they are able to use the outline algorithm in production sites.
Headings Map does not currently support the aria-label and aria-labelledby attributes on sectioning elements in the HTML5 outline tab. I have been talking with the developer and he is working on fixing this issue. If you know of a good document outline testing tool that already takes aria-label and aria-labelledby into account, please share a link to it in the comments.
Once you have a good document structure testing tool, check that both the heading structure and the document outline display a logical order with no missing headings or missing section labels anywhere.
Download and use a screen reader
The best way to test the implied semantics that you get from using correct HTML is to download an actual screen reader and try navigating your site with it. NVDA is one of the most used screen readers used by real screen reader users. It’s also free!
Be aware that the default settings for NVDA are optimized for usage by blind users. These default settings can drive sighted users insane. To enjoy your time using NVDA, perform the following steps (steps are based on a Windows set up, I don't have a Mac):
Download NVDA and install it
Create a shortcut to NVDA in your task bar (You will be opening and closing it regularly while testing)
Open NVDA from the task bar
Find NVDA in your system tray
Right click the tray icon > "preferences" > "settings"
Select "mouse" in the left panel
Deselect "Enable mouse tracking" (You can now move your mouse without NVDA screaming at you)
Press "OK"
Right click the tray icon > "Tools" > "Speech Viewer" (You can now see a log of everything NVDA says, don't rely purely on this when testing though)
In the Speech Viewer, check the "Show Speech Viewer on Startup" checkbox (It will open the Speech Viewer when you open NVDA)
Familiarize yourself with some of the keyboard controls
To close NVDA, Right click the tray icon > "Exit" > "OK"
NVDA currently doesn't support <article> and <section> elements. There is an issue on GitHub for supporting <article> elements. When I began writing this article <section> elements were already supported. Support for <section> seems to have dropped for some reason. This means NVDA should be fixed. It doesn't mean you should stop using the correct semantics in your HTML.
Build your website with the document outline in mind then test the semantics with Headings Map and NVDA (or another screen reader). If you do, you will make your screen reader users very happy. You might even make the search engines happier too. 😊
Special thanks to Kevin Galvin (a principal consultant at me 2 accessibility) for advice around the usability issues of using a visually hidden <h1> element at the top of the page and suggesting aria-label as an alternative to using visually hidden headings.
The post How to Section Your HTML appeared first on CSS-Tricks.
How to Section Your HTML published first on https://deskbysnafu.tumblr.com/
0 notes
siliconwebx · 5 years
Text
How to Section Your HTML
The sectioning elements in HTML5 are <nav>, <aside>, <article>, and <section>. <body> is also kind of a sectioning element since all content lying inside of it is part of the default document section.
Here is a brief explanation of each sectioning element and how they are used:
<nav> - Equivalent to role="navigation". Major site navigation that consistently appears frequently across the site. Examples include the primary navigation, secondary navigation, and in-page navigation.
<aside> - Equivalent to role="complimentary". Content that is only tangentially related (or not related) to the main content. Think of something like a sidebar with supplementary information, a note within an article, or the outer container for a list of related articles at the bottom of a blog post.
<article> - Equivalent to role="article". Content that is self-contained in that it makes sense on its own when taken out of context. That could mean a widget, a blog post or even a comment within a blog post.
<section> - Equivalent to role="region". Content that needs extra context from its parent sectioning element to make sense. This is a generic sectioning element that is used whenever it doesn’t make sense to use the other more semantic ones.
Contents
This is a very long article that I suspect you will want to come back to and reference multiple times. To make that easier, here is a list of all the article headings:
Jump to article heading
When to use <nav>
A <nav> is unnecessary around a search form
Don’t use the word "nav" or "navigation" in the label
Questions to ask yourself
A <nav> doesn’t have to be a list of links
Avoid nesting an <aside> inside an <aside>
Article is like "Block"; Section is like "Element"
Comments sections
Don’t swap <div> for <section>
Headers and footers
What goes inside headers?
What goes inside footers?
Sectioning elements and the document outline algorithm
No browser supports the document outline algorithm
Sectioning content
The <main> element
You need to label your sections. Here are three methods.
Method 1: Add an aria-label attribute
The aria-label translation issue
Positives
Negatives
Method 2: Add a <h#> element to it
Heading placement
Only one heading of the highest level per sectioning element
The heading always comes first
Making visually hidden section labels out of headings
Headings are well-supported by structure analysis tools
Positives
Negatives
Method 3: Use an aria-labelledby attribute
Labels can be hidden without CSS
Major portability issue
No need to place the label near the sectioning element
Turn non-heading elements into section labels
Positives
Negatives
Only use one method at a time
Adding section labels to our example layout
Making Heading 1 be the first heading
Concerns with the simplified outline algorithm spec
Using aria on the example layout sectioning elements
Using aria-label
Using aria-labelledby
Results of using aria
What happens when you need h7?
Does your site have a good structure?
Download and use a screen reader
When to use <nav>
The <nav> element only ever needs to be used once per navigation block. Sub-navigation that is already contained inside a <nav> element does not need to be wrapped in a second <nav> element.
<nav aria-label="Primary"> <ul> <li><a href="#">Primary link</a></li> <li><a href="#">Primary link</a></li> <li> <a href="#">Primary link</a> <!-- <nav> element is *not* needed again here --> <ul> <li><a href="#">Secondary link</a></li> <li><a href="#">Secondary link</a></li> </ul> </li> </ul> </nav>
The <nav> element is intended for only major navigation blocks. "Major" is a very subjective term though. html5doctor.com has a pretty good explanation of when it is and isn’t appropriate to use <nav>, keep in mind that the following are opinions and not official W3C rulings:
The key phrase is ‘major’ navigation. We could debate all day about the definition of ‘major’, but to me it means:
Primary navigation
Site search
Secondary navigation (arguably)
In-page navigation (within a long article, for example)
While there isn’t any right or wrong here, a straw poll coupled with my own interpretation tells me that the following shouldn’t be enclosed by <nav>:
Pagination controls
Social links (although there may be exceptions where social links are the major navigation, in sites like About me or Flavours, for example)
Tags on a blog post
Categories on a blog post
Tertiary navigation
Fat footers
— html5doctor.com (strikethrough mine)
Breadcrumbs are another piece of content that should be wrapped in a <nav> element as evidenced by this W3C breadcrumb HTML example.
A <nav> is unnecessary around a search form
I disagree with HTML5 Doctor’s opinion that a site search form should be wrapped in a <nav> element (thus why I crossed it out). <nav> is intended to be wrapped around navigation links, not a form. The site search actually has its own special role that defines it as a search landmark. If you add role="search" to the search <form> element, it is announced to screen reader users as a search landmark. Screen reader users will also be able to navigate to it when navigating via landmarks. If there are multiple search forms on the page, they should be differentiated using aria-label or aria-labelledby (more details on these attributes later). Don’t include the word "search" in the aria label though — that’s like saying "image of" in image alt text; it’s unnecessary. Instead, focus on what the search form is searching through. So, for the global site search, giving it aria-label="site" would be appropriate.
<!-- <nav> is not needed on a search form. --> <!-- role="search" is enough --> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search" /> </label> <buton type="submit">Submit</button> </form>
A role="search" form won’t appear in a document outline but I think this is okay considering search forms are often small and self-contained. It still gets the majority of benefits that you get from using sectioning elements. Adding a sectioning element to the mix bombards the screen reader user with messages telling them that it is a search form (one for the sectioning element, one for the search role, and one for the search input label).
Don’t use the word "nav" or "navigation" in the label
Like with role="search", adding "navigation" to the label of a <nav> element only results in a screen reader saying "navigation" twice.
<nav aria-label="primary navigation"> <!-- Screen reader: "primary navigation navigation landmark" --> </nav> <nav aria-label="primary"> <!-- Screen reader: "primary navigation landmark" --> </nav>
Questions to ask yourself
That same HTML5 Doctor article lists two questions that you can ask yourself to help you figure out if something should be wrapped in a <nav> or not:
Would another sectioning element also be appropriate? If yes, maybe use that instead.
Would you add a link to it in a "skip to" block for accessibility? If not, then it might not be worth using a <nav> element.
In those cases where the navigation is too minor to justify the use of the <nav> element, <section> is most likely the element that you should use instead.
A <nav> doesn’t have to be a list of links
The most common use case for a <nav> is to wrap it around a list of links but it doesn’t have to be a list of links. If your navigation works in a different sort of way, you can still use the <nav> element.
<!-- Example taken from the <nav> element specification --> <!-- https://html.spec.whatwg.org/multipage/sections.html#the-nav-element:the-nav-element-5 --> <nav> <h1>Navigation</h1> <p>You are on my home page. To the north lies <a href="/blog">my blog</a>, from whence the sounds of battle can be heard. To the east you can see a large mountain, upon which many <a href="/school">school papers</a> are littered. Far up thus mountain you can spy a little figure who appears to be me, desperately scribbling a <a href="/school/thesis">thesis</a>.</p> <p>To the west are several exits. One fun-looking exit is labeled <a href="https://games.example.com/">"games"</a>. Another more boring-looking exit is labeled <a href="https://isp.example.net/">ISP™</a>.</p> <p>To the south lies a dark and dank <a href="/about">contacts page</a>. Cobwebs cover its disused entrance, and at one point you see a rat run quickly out of the page.</p> </nav>
In this same vein, it’s okay to have small bits like intro text in the <nav> element as long as the primary focus of the content is on the navigation links. Introductory content is best placed inside a <header> in the <nav> element. I’ll go into more depth on headers and footers later.
<nav> <header> <h2>In this section</h2> <p>This is some intro text describing what you will find in this section.</p> </header> <ul> <li><a href="#">Sub section one</a></li> <li><a href="#">Sub section two</a></li> </ul> </nav>
Avoid nesting an <aside> inside an <aside>
In the same way that <nav> shouldn’t really ever be nested inside another <nav> element, <aside> elements also tend not to be nested inside each other. <aside> is used to represent content that is tangentially related to the content around it. That means placing an aside inside an aside is basically announcing a tangent away from something that in itself is a tangent away from the main content.
<!-- Don't do this --> <aside aria-label="Side bar"> <aside> <h2>Share</h2> <ul> <!-- List of social media links --> </ul> </aside> <aside> <h2>Recommendations:</h2> <ul> <li> <article> <h2><a href="#">Related article title</a></h2> <p>Article description</p> </article> </li> <!-- List of recommended articles continues --> </ul> </aside> </aside>
If you have a sidebar that has multiple sections, don’t nest <aside> elements inside of <aside> elements like in the example above. Instead, make the sidebar a single <aside> and then use <section> (or another appropriate sectioning element) to create the different sections.
<!-- Do this instead --> <aside aria-label="Side bar"> <section> <h2>Share</h2> <ul> <!-- List of social media links --> </ul> </section> <section> <h2>Recommended articles:</h2> <ul> <li> <article> <h2><a href="#">Related article title</a></h2> <p>Article description</p> </article> </li> <!-- List of recommended articles continues --> </ul> </section> </aside>
Article is like "Block"; Section is like "Element"
<section> and <article> are easy to get confused with one another. If you are familiar with "Block Element Modifier" (BEM) syntax, then an easy way to think of the difference between the two is that an <article> is a bit like the "B" (or "Block") in BEM. It is a container that stores self-contained content that still makes sense when placed in a different context. Individual tweets on Twitter and each list item on a search results page would be considered <article> elements.
<section> is like the "E" (or "Element") in BEM. It is a sub-section that requires context from its parent sectioning element to make sense. <section> is a generic catch-all sectioning element that you use when it doesn’t make sense to use the other sectioning elements. So, if in doubt, go with <section>.
Note that if something is styled as a "Block" in BEM, that doesn't automatically mean that it is an <article> element. Same goes for BEM "Elements" and <section> elements. The element of something should be based on the meaning of the content, not how the content looks.
Comments sections
Something that may surprise people is that individual comments on a blog post are also considered articles, even though they are in reply to the main blog post. The <article> element wrapping around the main blog post should also wrap around the comments section though. This is to represent that the comments go with the main article.
<article> <h1>I am an awesome blog post!</h1> <p>I am some body text content.</p> <section> <h2>Comments</h2> <ul> <li> <article> <h2>Username</h2> <p>This is the comment body text.</p> <footer> <p> Meta data like post date makes sense in either the header or the footer. </p> </footer> </article> </li> </ul> </section> </article>
Don’t swap <div> for <section>
Just because we have these fancy sectioning elements now, it doesn’t mean that the good old <div> element has lost all of its usefulness. <div> has no semantic meaning, so it is quite useful whenever we are altering the HTML purely for the sake of styling purposes.
Let’s say that we have a blog post contained inside an <article> element that we need to wrap in something for the sake of styling purposes.
<!-- I need a wrapper element --> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article>
Reaching for the <section> element in this circumstance is not the right thing to do.
<!-- Do not do this --> <section class="wrapper"> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article> </section>
Though <section> is technically a generic element, <div> is the far more appropriate option in this circumstance. This new wrapping container is not meant to have any semantic meaning behind it and that is exactly what <div> is designed to be used for.
<!-- Use a <div> if the element is only used for styling purposes --> <div class="wrapper"> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article> </div>
Another way to remember this: if you can’t think of a meaningful heading to apply to a <section>, then it probably shouldn’t be a <section>.
Headers and footers
Although they don’t necessarily need to, sectioning elements may contain a single <header> and a single <footer> with the header being at the top of the section and the footer being at the bottom.
Sectioning elements can be nested inside one another as many times as is needed based on the content.
The header and footer in a sectioning element can also contain sectioning elements.
The one major restriction around nesting sectioning elements is that headers and footers cannot be nested inside other headers and footers.
Nesting headers and footers inside one another is not allowed.
What goes inside headers?
Headers are used for introductory content. Appropriate things to include in <header> elements include (but are not limited to):
The heading element (<h1>-<h6>)
An introductory paragraph or statement.
A profile picture
A logo
A search form
Primary navigation
Author’s name
Post/updated date
Meta data
Social media links
What goes inside footers?
Footer elements primarily hold things like meta data and minor supporting content. Appropriate things to include in <footer> elements include (but are not limited to):
Copyright information
Legalities
Footnotes
Low priority site navigation
Author’s name
Post/updated date
Meta data
Social media links
You will notice that there is some cross over between the header and the footer in terms of content that is appropriate to both. This is mostly because meta-type content fits well in either element. It mainly comes down to the design that you are trying to achieve. <header> elements do tend to signify that the content inside of them is of greater importance than the content inside of a <footer> element though.
Sectioning elements and the document outline algorithm
An important thing to know about these sectioning elements is that they are all supposed to feature a <h#> element inside of them (or be labeled in some other way, but more on that later). This is primarily for the sake of something called the document outline algorithm. This is an algorithm that uses sectioning elements to help determine what level a heading (<h#>) should be without having to rely exclusively on the number that the developer has provided. So, have you ever wondered whether or not it’s okay to have more than one <h1> on a page? This is meant to make that a non-issue (but hold on for a sec, because there is more to the story).
<!-- No Document outline algorithm --> <article> <h1>Primary heading</h1> <h2>Secondary heading</h2> <p>Some text.</p> <h3>Tertiary heading</h3> <p>Some text.</p> </article>
<!-- With document outline algorithm --> <article> <h1>Primary heading</h1> <!-- Recognized as <h1> --> <!-- sectioning element sets new heading level context --> <section> <h1>Secondary heading</h1> <!-- Recognized as <h2> --> <p>Some text.</p> <h2>Tertiary heading</h2> <!-- Recognized as <h3> --> <p>Some text.</p> </section> </article>
There is a lot more to learn about the document outline algorithm. I’ll stop here though because...
No browser supports the document outline algorithm
There is not a single browser that supports this method of creating a heading structure. This is a shame. It would make building accessible websites much easier if we didn’t have to worry so much about using the correct heading level all the time.
As far as I’m aware, there are two main reasons why no browser has implemented the algorithm. One is that browser vendors are afraid of breaking the heading structure of sites that have used sectioning elements incorrectly. The other reason is that the current document outline algorithm spec is difficult to implement and no browser vendor has been willing to put the time into implementing it yet.
In reference to the first reason, there is a long discussion about incorporating a new <h> element instead of using the <h1> element to tell browsers to use the document outline algorithm. I was in favor of this new <h> element idea until I realized that an attribute on the <html> element or adding a <meta> tag to the <head> would work even better as a means of telling browsers it was safe to use the algorithm. It is also better for headings to fall back to a <h1> in unsupported browsers than falling back to a <span>.
If you would like to play around with this <h> concept though, there is a plugin called hfill. It allows you to nest <hx> headings inside sectioning elements to create the document outline without having to worry about heading levels so much. There is a demo available for you to try it out. The major flaw in this plugin though is that the only way to increment heading levels is by nesting sectioning elements inside one another. There is no <h1>-is-greater-than-<h2> dynamic in this plugin which is the main reason I fell out of love with this <h> element idea. This lack of heading hierarchy would make CMS rich text editors far too difficult for clients to use.
As for the issue around implementation difficulty, work is being done to produce a simplified spec that browser vendors are more likely to adopt. The document outline algorithm has been in the HTML specifications for years. Hopefully this simplified spec will allow the algorithm to become a reality.
Although the algorithm is not supported anywhere yet, we can still build with the algorithm in mind. If we build with it in mind, then we gain the following benefits:
We future-proof our sites in case the algorithm ever does get implemented.
We can significantly improve the user experience for screen reader users.
We potentially improve search engine optimization (SEO) due to search engines being able to better understand the site’s content.
We can create a better user experience for users by allowing them to use native browser features that make use of sectioning elements, like Reader Mode.
Sectioning content
Take a look at this mock-up layout I put together and think about how you might split it up into sections.
This is how I would split the layout up into sectioning elements (only the solid lines represent sectioning elements).
In terms of HTML markup, it looks like this:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
The <main> element
There is a very important semantic element that I used in the markup above that I haven’t covered yet and that is the <main> element. The <main> element represents the primary content of the page. It is not supposed to feature any side bars or navigation elements in it. You also must not have more than one <main> element on the page unless all other <main> elements on the page have a hidden attribute applied to them (this is for the sake of SPAs).
The <main> element is not a sectioning element. This means that it doesn’t help contribute to the document outline algorithm and it can’t feature a <header> or <footer> element as a direct child. It is a landmark element though so screen reader users are able to navigate to it quite easily.
I’m not 100% sure if using <article> in the <main> element like I have done above is necessary. Semantically, it does make sense. The main content is self-contained, thus justifying use of the <article> element in this way. From a document outline algorithm perspective, the <article> element also helps with the document structure.
From a usability point of view, it feels a bit unnecessary and the document outline algorithm doesn’t even work anywhere at the moment. I’m going to continue using it throughout my examples but I would be interested to know what other people think about this in the comments section.
You need to label your sections. Here are three methods.
I am going to be saying the word "label" a lot throughout this article. Keep in mind that I am not talking about the <label> element. The <label> element is not used to label sectioning elements.
Sectioning elements require labels so that screen reader users are able to quickly identify what content they can find inside that particular section of the site. I consider using sectioning elements without providing associated section labels as an accessibility fail, unless it is the only one of its type on the page. It is also recommended that the exact same label text not be used on multiple sectioning elements (or heading elements). This makes each section more recognizable to screen reader users which helps them navigate the site more easily.
There are three ways to label a sectioning element. In the following examples, I refer to "transport" and "portability" as a way of explaining how easy it is to save the section into a component and use that component multiple times in multiple different contexts.
I also provide lists of positives and negatives in the examples as well. In these lists, I assume that you want the section label to be readable by screen readers but hidden from sighted users.
Method 1: Add an aria-label attribute
This is the quickest and easiest way to label a sectioning element.
<section aria-label="Label for this section"> <p>Content for this section</p> </section>
#The aria-label translation issue
The main draw back of aria-label (at the time of writing) is that most browsers are unable to translate these values for users who speak a different language than you. The developers at Google recently fixed this bug in Chrome, however this is still a problem for every other browser.
If your website has a large international audience or you know that many of your users do not speak your language, you should probably avoid using this attribute until all browsers support the translation of this property. If you don’t have those sorts of users, it’s pretty safe to assume that the non-sighted users viewing your site are able to understand your language — well enough to be able to navigate your site, anyway.
If you need more convincing, let's say your site has very few international users. That means your users generally come from the same country as you. If they come from the same country then they are likely to speak the same language as you, so there is already a fairly small percentage of your users that don’t understand the native language of your site. Now take into account that aria-label only affects screen reader users. That is now only a fraction of an already small percentage of your users who will experience the issue. And now consider that Chrome (by far the most popular browser in the world) now supports translation of the aria-label attribute. The user has to also not be using an up to date version of Chrome as their browser for the translation issue to be a problem. If you factor all of that together, it is highly probable that you may not have any users who are both able to perceive the aria-label attributes and are incapable of comprehending what they say. This makes me feel like the bad multi-lingual support in aria-label isn’t really worth worrying that much about unless you have a large international audience or you have many users that you know do not speak your language.
#Positives
Super quick and easy to implement.
Doesn’t affect heading structure.
Makes components easy to transport.
Is invisible to sighted users.
#Negatives
Not translated into other languages in non-Chrome browsers (at time of writing).
Often not supported by page structure analysis tools.
Confusion can arise from not knowing what level other headings inside the section should be at.
Method 2: Add a <h#> element to it
By <h#> I mean <h1>, <h2>, <h3>,<h4>,<h5>, or <h6> depending on what makes sense. Adding a heading to a sectioning element is a quick way to label it.
#Heading placement
The heading can be placed either directly in the sectioning element, like this:
<section> <h1>Heading</h1> <p>content</p> </section>
...or placed inside the <header> element:
<section> <header> <h1>Heading</h1> <p>I'm a byline</p> </header> <p>Content</p> </section>
You can also place as many <div> wrapper elements between the sectioning element and the heading as you want.
<!-- This is perfectly fine --> <section> <div> <header> <div> <h1>Heading</h1> <p>I'm a byline</p> </div> </header> <p>Content</p> </div> </section>
#Only one heading of the highest level per sectioning element
There should really only be one heading of the highest level in a sectioning element. The spec says that when there are multiple top level headings or headings of a higher level than the first, the browser is supposed to close the previous sectioning element and start a new one of the same type.
The first element of heading content in an element of sectioning content represents the heading for that explicit section. Subsequent headings of equal or higher rank start new implied subsections that are part of the previous section’s parent section. Subsequent headings of lower rank start new implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.
—HTML 5.3, Headings and Sections
In reality, the browser uses the first heading as the section label but these implied sections are never created. It just announces the heading as is when it encounters it. It’s not earth-shatteringly bad but it is somewhat confusing.
<!-- Avoid this: --> <section> <h2>Heading level two labeling a section</h2> <p>Content</p> <!-- Don't use same level or higher headings as the one labeling the section --> <h2>This is also a heading level two</h2> <p>Content</p> </section> <!-- Do this instead: --> <div> <section> <h2>Heading level two labeling a section</h2> <p>Content</p> </section> <section> <h2>Heading level two labeling a different section</h2> <p>Content</p> </section> </div>
#The heading always comes first
If a sectioning element has a <h#> element, that top level heading should always be the very first piece of content inside that sectioning element. Failing to do so counts as an accessibility fail.
If you find yourself needing to place content before your heading (like an image, for example), you can use Flexbox to rearrange the visual order. This will allow it to look like the image comes before the heading but in the markup the heading comes before the image. There is a bug in IE that will sometimes cause text to not wrap in a flex-direction: column; element. You can work around this issue by applying a max-width to the flex-child element.
<!-- Don't do this --> <section> <img src="image.jpg" alt="Don't place content or images before the heading" /> <h2>Headings should always come first</h2> <p>Place regular content after the heading</p> </section> <!-- Do this instead --> <section class="example"> <h2>Headings should always come first</h2> <img src="image.jpg" alt="Don't place content or images before the heading" /> <p>Place regular content after the heading</p> </section> <style> .example { display: flex; flex-direction: column; } .example img { order: -1; } </style>
Note that rearranging the visual order to satisfy WCAG Guideline 1.3.2: Meaningful Sequence can conflict directly with WCAG Guideline 2.4.3: Focus Order. For example, if that image is a link to an article and the heading you are placing it above is also a link to the article, placing the heading first breaks the focus order. Placing the image first breaks the meaningful sequence.
In situations like this where these two guidelines conflict with one another, my opinion is that the 1.3.2: Meaningful Sequence guideline is the more important guideline to follow if you aren’t able to resolve the conflict in some way. Failing focus order leads to the user suffering a moment of discomfort as they are tabbing through the content and focus is sent to an unexpected location. Failing to follow a meaningful sequence leads to a confused user unsure of the relationship between different bits of content.
#Making visually hidden section labels out of headings
Headings are visible to sighted users by default. This makes them super useful if you want the heading to be visible. A lot of the time, we don’t want the label for our sectioning element to be visible though. In order to stop our sighted users from seeing the label, we need to use some CSS.
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <section> <h1 class="visually-hidden">Heading</h1> <p>content</p> </section>
#Headings are well-supported by structure analysis tools
Headings also have a huge advantage for developers in that any page structure analysis tool that you can find will have support for them. This makes heading structures easy to test and debug. The other two section labeling methods have very poor support in testing tools. Not even the official W3C Validator service supports the alternatives at the moment. I posted an issue to have this fixed — please consider helping to fix the issue if you are good at coding in Java.
#Positives
Quick to implement.
Reliably appears in page structure analysis tools making it easy to test and debug.
All browsers will translate the text into other languages.
No confusion over what level other headings inside the section should be.
#Negatives
Affects document heading structure.
Need to ensure that the heading is at the correct level before use.
Visible to the user by default.
Requires CSS to hide the heading from visual users.
Can make components less portable due to heading structure requirements.
Method 3: Use an aria-labelledby attribute
This is what it looks like to create a hidden section label using aria-labelledby.
<section aria-labelledby="unique-id"> <div hidden id="unique-id">Label for this section</div> <p>Content for this section</p> </section>
#Labels can be hidden without CSS
Note that I used the hidden attribute in the example to hide the div rather than a visually-hidden CSS class. aria-labelledby is able to read out text that is normally hidden from screen reader users. This adds the bonus effect of preventing the text from being read out twice by the screen reader. Don’t use the aria-hidden attribute though. Screen readers will not find the label text. Well, NVDA couldn’t find the label text when I tested it. I’m not sure about other screen readers.
#Major portability issue
aria-labelledby is the most difficult to use out of all the section labeling methods. The main aspect that makes it difficult to use is that the aria-labelledby attribute works off IDs. Things always get more complicated whenever IDs are involved. This is due to web pages only being allowed to have a single instance of an ID on the page at any one time. This makes component portability difficult.
Due to this portability issue, I would really only recommend this option if you need to support a multi-lingual audience and don’t want to mess around with the heading structure.
#No need to place the label near the sectioning element
You don’t need to place the element with the label text inside or near the section element that it labels. The text for the label can be placed in a completely different location to the sectioning element. This is thanks to the ID linking the two elements together. I’m not necessarily saying that it is a good idea to do this, but it is a feature of aria-labelledby that you should be aware of.
<div hidden id="unique-id">Label for this section</div> <!-- 1,000 lines of other HTML --> <section aria-labelledby="unique-id"> <p>Content for this section</p> </section>
#Turn non-heading elements into section labels
There is one other key reason you may want to use aria-labelledby. If you have a visible non-heading element on the page that you want to use as the label for a section, aria-labelledby is perfect for this. A <legend> element inside a <fieldset> is a common use case for this. This doesn’t mean that you have to wrap fieldsets in sectioning elements. I’m just pointing it out in case you spot a need for it.
<section aria-labelledby="section_label"> <fieldset> <legend id="section_label"> I am both the fieldset legend and the section label </legend> <!-- Form fields go here --> </fieldset> </section>
#Positives
All browsers will translate the text into other languages.
Can assign a non-heading element as the section label.
Text for the label does not need to be placed near the section it is labeling.
#Negatives
Requires the use of IDs to work.
Difficult to transport.
It can potentially be difficult to track down where the text for the label is stored in your source code.
Text is visible by default unless a hidden attribute is used.
Text might get read out twice by some screen readers if the text is not hidden.
Confusion can arise from not knowing what level other headings inside the section should be at.
Only use one method at a time
Don’t use a <h#>, an aria-label and/or an aria-labelledby attribute at the same time on the same sectioning element. Only every use one labeling method at a time for each sectioning element. Using multiple methods is super confusing and leads to the label being overwritten. It’s a bit like declaring the same property twice in CSS. I wasn’t sure how a screen reader would actually handle this so I created the most ridiculous <section> ever and ran it through NVDA.
<!-- Don't do this --> <section aria-label="Is this the section label?" aria-labelledby="is_this_the_label"> <h1>Or is this the section label?</h1> <p id="is_this_the_label">Only ever use one at a time.</p> </section>
This is the order of priority that NVDA gave to the various labeling methods from strongest to weakest:
aria-labelledby
aria-label
<h#>
Adding section labels to our example layout
For a long time, I used headings as the only means of labeling sections. The poor multi-lingual support provided by aria-label scared me; and aria-labelledby was far too cumbersome to be my primary labeling method. We run into a bit of an issue though if we use only headings to label sections. I’ll show you what I mean.
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <h2 class="visually-hidden">Primary</h2> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <h2 class="visually-hidden">Secondary</h2> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <h2 class="visually-hidden">Sidebar</h2> <section> <h3>Share</h3> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h3>Recommended</h3> <ul> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
If we look at our heading structure now, it will look like this (italics = visually hidden; bold = visible):
li.no-list-dot::before { display: none; }
<h2> Primary [nav]
<h2> Secondary [nav]
<h1> Main article heading
<h2> Article secondary heading
<h2> Sidebar
<h3> Share
<h3> Recommended
<h4> Related article
<h4> Related article
Notice that our <h1> heading isn’t at the top of the list? It really doesn’t feel right having two <h2> headings above the <h1> heading.
This form of heading structure is actually allowed by the W3C so it doesn’t count as an accessibility fail. I still think that this is a pretty bad UX for screen reader users though. It is not a logical progression from <h1> to <h2>. It makes the most sense if the first heading you encounter on the page is a <h1> then progress into <h2> then <h3> and so on.
Making Heading 1 be the first heading
For a very long time, I thought the absolute best way to handle this conundrum was to make the <h1> visually hidden and have it be the very first piece of content on the page. The thing that everyone thinks is the <h1> actually becomes a <h2>.
This is what that sort of structure looks like in practice:
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <!-- Don't do this --> <body> <header> <h1 class="visually-hidden">Main article heading</h1> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <h2 class="visually-hidden">Primary</h2> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <h2 class="visually-hidden">Secondary</h2> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h2><span class="visually-hidden">Body:</span> Main article heading</h2> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h3>Article secondary heading</h3> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <h2 class="visually-hidden">Sidebar</h2> <section> <h3>Share</h3> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h3>Recommended</h3> <ul> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Now we have a document outline that looks like this (italics = visually hidden; bold = visible):
<h1> Main article heading
<h2> Primary [nav]
<h2> Secondary [nav]
<h2> Body: Main article heading
<h3> Article secondary heading
<h2> Sidebar
<h3> Share
<h3> Recommended
<h4> Related article
<h4> Related article
This mostly feels right. The <h1> is at the top and it all flows down perfectly with the <h2> elements representing major page sections and the <h3> elements representing sub sections. The main awkward bit is that the actual <h1> and the thing that everyone thinks is a <h1> are essentially duplicates of one another.
It wasn’t until I wrote up the first version of this article, had it nearly published, then had it thrown out the window, that I started to think differently. I talked with two accessibility consultants about the issue. They both agreed that, though this is a clever technical solution to the problem, it detracts from the experience of the very people that it is trying to help.
The issue is that when every other website in the world places the <h1> heading at the top of the main content area, that is what screen reader users come to expect. When your site is the special snowflake that does things differently, it confuses screen reader users and it takes them some time to figure out how your heading structure is supposed to work.
So, with that in mind, I’ve settled on a new method for handling the labeling of sectioning elements. Basically, any time I would have used a visually hidden heading, I would use an aria-label attribute now instead. If the site has a large non-native speaking audience, I would use aria-labelledby instead of aria-label.
Concerns with the simplified outline algorithm spec
If the simplified outline algorithm is approved in its current state, we will actually need to start structuring our sites like the visually hidden <h1> example anyway (just replace the <h2>, <h3> and <h4> elements with <h1> elements).
The original spec aimed to create the outline through the labeling of sectioning elements. This new spec is clearly aimed at trying to create the outline purely through heading levels. The algorithm basically calculates the heading level based on the number of ancestor sectioning elements a heading has plus the heading’s base heading level value. It's a bit more nuanced than that in the spec, but that is the general idea of how it works in simple terms.
The simplified algorithm currently makes no mention of aria-label or aria-labelledby. This means that those attributes will not help contribute to the document outline that the simplified algorithm generates. With a lack of aria-label support, this would mean labeling a sectioning element with aria-label could easily lead to skipped heading levels deeper in the tree.
<!-- Simplified algorithm skipped heading levels issue --> <body> <main> <h1>Primary heading for the page</h1> <!-- interpreted as <h1> --> <p>This is some content</p> </main> <!-- sectioning elements increase heading levels --> <aside aria-label="Side bar"> <!-- aria-label does not contribute --> <section> <h1>Share</h1> <!-- interpreted as <h3> --> <ul> <!-- list of social media links --> </ul> </section> <section> <h1>Recommended articles:</h1> <!-- interpreted as <h3> --> <ul> <!-- list of recommended articles --> </ul> </section> </aside> </body>
The simplified spec also considers it invalid to:
not have a heading level of 1 at the root of the document (which is problematic if you are placing the main body content inside an <article> element); and
not have a heading level of 1 be the first heading in a document (which, for the most part, is okay, unless you need to use a heading in the site header or in a left side bar).
It does, however, allow for there to be more than one level 1 heading at the root of the document, which I find very odd and bad for accessibility (though my concern about this seems to have been ignored).
I have voiced the issues I have with the spec and proposed possible solutions in the GitHub discussion.
For the moment, it is still best to use aria-label and/or aria-labelledby attributes instead of visually hidden headings to label sectioning elements. It isn’t worth diminishing the experience of our present day users for the sake of a spec that hasn’t even been finalized or accepted yet.
Using aria on the example layout sectioning elements
Using aria-label
This is what the HTML structure looks like if we use aria-label attributes to label the sectioning elements:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav aria-label="Primary"> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav aria-label="Secondary"> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside aria-label="Sidebar"> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Here is the layout in CodePen in case you want to have a play around with it (sorry mobile users, it's not mobile friendly):
See the Pen Mock up page layout v2 (sections article) by Daniel Tonon (@daniel-tonon) on CodePen.
Using aria-labelledby
But let’s assume that you have a huge international audience that speaks all sorts of languages. In that case, it is better to use the aria-labelledby attribute. Here is what that would look like:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav aria-labelledby="primary-nav-label"> <div id="primary-nav-label" hidden>Primary</div> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-labelledby="search-label"> <div id="search-label" hidden>Site</div> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav aria-labelledby="secondary-nav-label"> <div id="secondary-nav-label" hidden>Secondary</div> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside aria-labelledby="sidebar-label"> <div id="sidebar-label" hidden>Sidebar</div> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Results of using aria
The heading structure for the site at this point looks like this:
<h1> Main article heading
<h2> Article secondary heading
<h2> Share
<h2> Recommended
<h3> Related article
<h3> Related article
The document outline (assuming that the original outline algorithm is implemented) looks like this:
<body> Document
<nav> Primary
<nav> Secondary
<article> Main article heading
<section (implied)> Article secondary heading
<aside> Sidebar
<section> Share
<section> Recommended
<article> Related article
<article> Related article
You might be thinking that the document outline looks a bit bare. Shouldn’t things like the header and footer and search be announced in there as well? Keep in mind that this is just the explicit stuff. We get a lot of implicit information provided to the user for free by using correct HTML elements in a good structure. This is a simplified version of how a screen reader user might experience the site:
[Text used in the <title> element]
Banner landmark
Link, site logo [(on focus) "go to home page"]
"Primary" navigation landmark
[List of navigation links]
"Site" search landmark
"Secondary" navigation landmark
[List of navigation links]
Main landmark
"Main article heading" article landmark, heading level 1
[Content]
Heading level 2, "Article secondary heading"
[Content]
"Sidebar" complimentary landmark
"Share" region landmark, heading level 2
[List of share links]
"Recommended" region landmark, heading level 2
List with 2 items
Item, "Related article" article landmark, heading level 3
[Content]
Item, "Related article" article landmark, heading level 3
[Content]
Content info landmark
[List of footer links]
As you can see, the site structure becomes quite clear and understandable to screen reader users when you factor in all of the extra implicit information that you get from using a good HTML structure
So, even though no browser supports the document outline algorithm, it is still worth putting some effort into thinking about the outline. Screen readers still tell users what type of section something is, where sections start and (sometimes) end (depends on the screen reader), and what the section label is. This means that your efforts to make a good document structure do not go to waste.
This type of structure comes with multiple benefits:
The page is 100% compatible with the document outline algorithm, future proofing it in-case the algorithm is ever implemented in a real browser.
The heading structure is completely logical.
Screen reader users navigating via headings can quickly jump to important information.
Screen reader users navigating via landmarks have lots of useful landmarks to move about the page.
Screen reader users are able to quickly understand what each section contains without having to read any of the content inside of them.
Content is grouped into semantic sections, so screen reader users do not get confused when leaving one section and entering another.
Search engines are able to better understand what information each section holds, which could potentially improve SEO.
Sighted users can take advantage of native browser features like Reader Mode.
What happens when you need h7?
There is one more sticking point when it comes to labeling sectioning elements that I haven’t addressed yet. Let’s say you have somehow managed to use up all six native heading levels and are now stuck needing one more. What do you do?
You could use the aria-labelledby technique if it is just for the sake of labeling a section. Let’s say that you really want this heading to appear in the heading structure though, or maybe you just want to avoid using IDs as much as possible. Whatever the reason, you need an <h7> element but <h7> doesn’t exist.
This is when the aria-level attribute comes to the rescue. The aria-level attribute will define what the heading level should be for elements that have role="heading" applied to them. This is how the W3C recommend creating a <h7> element:
<div role="heading" aria-level="7">This is a valid heading level 7 element</div>
Not all screen readers support this syntax. I know that JAWS treats these like <h2> elements rather than <h7> elements. If you know of any screen readers that this doesn’t work in, please report the bug to the screen reader developer and also leave a comment down below.
When I need to reach for an <h7>, I’ll often use the implied role="heading" from an <h6> element instead. The aria-level attribute will override the implicit "6" level of the <h6> element. This isn’t exactly endorsed by the W3C though. It is cleaner and will allow the heading to still appear in document outline and heading structure testing tools (though they will typically appear as <h6> or <h2> level headings, not as <h7> level headings).
<h6 aria-level="7">This is also a valid heading level 7 element</h6>
By using aria-level, you now have access to an infinite number of heading levels!
Does your site have a good structure?
Now that you know how to do a proper HTML structure, are you able to apply what you have learned to your website?
I found a pretty good browser extension called "Headings Map" that is available for both Chrome and Firefox. This extension will allow you to easily see both a flat heading structure representation of your site (i.e. how all browsers currently read the heading structure) and what the document structure looks like in a browser that supports the document outline algorithm (i.e. how a theoretical future browser that supports the outline algorithm would present the site structure). The HTML5 Outline view needs to be enabled in the settings menu first. This is to prevent users from being fooled into thinking that they are able to use the outline algorithm in production sites.
Headings Map does not currently support the aria-label and aria-labelledby attributes on sectioning elements in the HTML5 outline tab. I have been talking with the developer and he is working on fixing this issue. If you know of a good document outline testing tool that already takes aria-label and aria-labelledby into account, please share a link to it in the comments.
Once you have a good document structure testing tool, check that both the heading structure and the document outline display a logical order with no missing headings or missing section labels anywhere.
Download and use a screen reader
The best way to test the implied semantics that you get from using correct HTML is to download an actual screen reader and try navigating your site with it. NVDA is one of the most used screen readers used by real screen reader users. It’s also free!
Be aware that the default settings for NVDA are optimized for usage by blind users. These default settings can drive sighted users insane. To enjoy your time using NVDA, perform the following steps (steps are based on a Windows set up, I don't have a Mac):
Download NVDA and install it
Create a shortcut to NVDA in your task bar (You will be opening and closing it regularly while testing)
Open NVDA from the task bar
Find NVDA in your system tray
Right click the tray icon > "preferences" > "settings"
Select "mouse" in the left panel
Deselect "Enable mouse tracking" (You can now move your mouse without NVDA screaming at you)
Press "OK"
Right click the tray icon > "Tools" > "Speech Viewer" (You can now see a log of everything NVDA says, don't rely purely on this when testing though)
In the Speech Viewer, check the "Show Speech Viewer on Startup" checkbox (It will open the Speech Viewer when you open NVDA)
Familiarize yourself with some of the keyboard controls
To close NVDA, Right click the tray icon > "Exit" > "OK"
NVDA currently doesn't support <article> and <section> elements. There is an issue on GitHub for supporting <article> elements. When I began writing this article <section> elements were already supported. Support for <section> seems to have dropped for some reason. This means NVDA should be fixed. It doesn't mean you should stop using the correct semantics in your HTML.
Build your website with the document outline in mind then test the semantics with Headings Map and NVDA (or another screen reader). If you do, you will make your screen reader users very happy. You might even make the search engines happier too. 😊
Special thanks to Eric Bailey (accessibility adviser for CSS Tricks) and Kevin Galvin (a principal consultant at me 2 accessibility) for their advice around the usability issues of using a visually hidden <h1> element at the top of the page and suggesting aria-label as an alternative to using visually hidden headings.
The post How to Section Your HTML appeared first on CSS-Tricks.
😉SiliconWebX | 🌐CSS-Tricks
0 notes
suzanneshannon · 5 years
Text
How to Section Your HTML
The sectioning elements in HTML5 are <nav>, <aside>, <article>, and <section>. <body> is also kind of a sectioning element since all content lying inside of it is part of the default document section.
Here is a brief explanation of each sectioning element and how they are used:
<nav> - Equivalent to role="navigation". Major site navigation that consistently appears frequently across the site. Examples include the primary navigation, secondary navigation, and in-page navigation.
<aside> - Equivalent to role="complimentary". Content that is only tangentially related (or not related) to the main content. Think of something like a sidebar with supplementary information, a note within an article, or the outer container for a list of related articles at the bottom of a blog post.
<article> - Equivalent to role="article". Content that is self-contained in that it makes sense on its own when taken out of context. That could mean a widget, a blog post or even a comment within a blog post.
<section> - Equivalent to role="region". Content that needs extra context from its parent sectioning element to make sense. This is a generic sectioning element that is used whenever it doesn’t make sense to use the other more semantic ones.
Contents
This is a very long article that I suspect you will want to come back to and reference multiple times. To make that easier, here is a list of all the article headings:
Jump to article heading
When to use <nav>
A <nav> is unnecessary around a search form
Don’t use the word "nav" or "navigation" in the label
Questions to ask yourself
A <nav> doesn’t have to be a list of links
Avoid nesting an <aside> inside an <aside>
Article is like "Block"; Section is like "Element"
Comments sections
Don’t swap <div> for <section>
Headers and footers
What goes inside headers?
What goes inside footers?
Sectioning elements and the document outline algorithm
No browser supports the document outline algorithm
Sectioning content
The <main> element
You need to label your sections. Here are three methods.
Method 1: Add an aria-label attribute
The aria-label translation issue
Positives
Negatives
Method 2: Add a <h#> element to it
Heading placement
Only one heading of the highest level per sectioning element
The heading always comes first
Making visually hidden section labels out of headings
Headings are well-supported by structure analysis tools
Positives
Negatives
Method 3: Use an aria-labelledby attribute
Labels can be hidden without CSS
Major portability issue
No need to place the label near the sectioning element
Turn non-heading elements into section labels
Positives
Negatives
Only use one method at a time
Adding section labels to our example layout
Making Heading 1 be the first heading
Concerns with the simplified outline algorithm spec
Using aria on the example layout sectioning elements
Using aria-label
Using aria-labelledby
Results of using aria
What happens when you need h7?
Does your site have a good structure?
Download and use a screen reader
When to use <nav>
The <nav> element only ever needs to be used once per navigation block. Sub-navigation that is already contained inside a <nav> element does not need to be wrapped in a second <nav> element.
<nav aria-label="Primary"> <ul> <li><a href="#">Primary link</a></li> <li><a href="#">Primary link</a></li> <li> <a href="#">Primary link</a> <!-- <nav> element is *not* needed again here --> <ul> <li><a href="#">Secondary link</a></li> <li><a href="#">Secondary link</a></li> </ul> </li> </ul> </nav>
The <nav> element is intended for only major navigation blocks. "Major" is a very subjective term though. html5doctor.com has a pretty good explanation of when it is and isn’t appropriate to use <nav>, keep in mind that the following are opinions and not official W3C rulings:
The key phrase is ‘major’ navigation. We could debate all day about the definition of ‘major’, but to me it means:
Primary navigation
Site search
Secondary navigation (arguably)
In-page navigation (within a long article, for example)
While there isn’t any right or wrong here, a straw poll coupled with my own interpretation tells me that the following shouldn’t be enclosed by <nav>:
Pagination controls
Social links (although there may be exceptions where social links are the major navigation, in sites like About me or Flavours, for example)
Tags on a blog post
Categories on a blog post
Tertiary navigation
Fat footers
— html5doctor.com (strikethrough mine)
Breadcrumbs are another piece of content that should be wrapped in a <nav> element as evidenced by this W3C breadcrumb HTML example.
A <nav> is unnecessary around a search form
I disagree with HTML5 Doctor’s opinion that a site search form should be wrapped in a <nav> element (thus why I crossed it out). <nav> is intended to be wrapped around navigation links, not a form. The site search actually has its own special role that defines it as a search landmark. If you add role="search" to the search <form> element, it is announced to screen reader users as a search landmark. Screen reader users will also be able to navigate to it when navigating via landmarks. If there are multiple search forms on the page, they should be differentiated using aria-label or aria-labelledby (more details on these attributes later). Don’t include the word "search" in the aria label though — that’s like saying "image of" in image alt text; it’s unnecessary. Instead, focus on what the search form is searching through. So, for the global site search, giving it aria-label="site" would be appropriate.
<!-- <nav> is not needed on a search form. --> <!-- role="search" is enough --> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search" /> </label> <buton type="submit">Submit</button> </form>
A role="search" form won’t appear in a document outline but I think this is okay considering search forms are often small and self-contained. It still gets the majority of benefits that you get from using sectioning elements. Adding a sectioning element to the mix bombards the screen reader user with messages telling them that it is a search form (one for the sectioning element, one for the search role, and one for the search input label).
Don’t use the word "nav" or "navigation" in the label
Like with role="search", adding "navigation" to the label of a <nav> element only results in a screen reader saying "navigation" twice.
<nav aria-label="primary navigation"> <!-- Screen reader: "primary navigation navigation landmark" --> </nav> <nav aria-label="primary"> <!-- Screen reader: "primary navigation landmark" --> </nav>
Questions to ask yourself
That same HTML5 Doctor article lists two questions that you can ask yourself to help you figure out if something should be wrapped in a <nav> or not:
Would another sectioning element also be appropriate? If yes, maybe use that instead.
Would you add a link to it in a "skip to" block for accessibility? If not, then it might not be worth using a <nav> element.
In those cases where the navigation is too minor to justify the use of the <nav> element, <section> is most likely the element that you should use instead.
A <nav> doesn’t have to be a list of links
The most common use case for a <nav> is to wrap it around a list of links but it doesn’t have to be a list of links. If your navigation works in a different sort of way, you can still use the <nav> element.
<!-- Example taken from the <nav> element specification --> <!-- https://html.spec.whatwg.org/multipage/sections.html#the-nav-element:the-nav-element-5 --> <nav> <h1>Navigation</h1> <p>You are on my home page. To the north lies <a href="/blog">my blog</a>, from whence the sounds of battle can be heard. To the east you can see a large mountain, upon which many <a href="/school">school papers</a> are littered. Far up thus mountain you can spy a little figure who appears to be me, desperately scribbling a <a href="/school/thesis">thesis</a>.</p> <p>To the west are several exits. One fun-looking exit is labeled <a href="https://games.example.com/">"games"</a>. Another more boring-looking exit is labeled <a href="https://isp.example.net/">ISP™</a>.</p> <p>To the south lies a dark and dank <a href="/about">contacts page</a>. Cobwebs cover its disused entrance, and at one point you see a rat run quickly out of the page.</p> </nav>
In this same vein, it’s okay to have small bits like intro text in the <nav> element as long as the primary focus of the content is on the navigation links. Introductory content is best placed inside a <header> in the <nav> element. I’ll go into more depth on headers and footers later.
<nav> <header> <h2>In this section</h2> <p>This is some intro text describing what you will find in this section.</p> </header> <ul> <li><a href="#">Sub section one</a></li> <li><a href="#">Sub section two</a></li> </ul> </nav>
Avoid nesting an <aside> inside an <aside>
In the same way that <nav> shouldn’t really ever be nested inside another <nav> element, <aside> elements also tend not to be nested inside each other. <aside> is used to represent content that is tangentially related to the content around it. That means placing an aside inside an aside is basically announcing a tangent away from something that in itself is a tangent away from the main content.
<!-- Don't do this --> <aside aria-label="Side bar"> <aside> <h2>Share</h2> <ul> <!-- List of social media links --> </ul> </aside> <aside> <h2>Recommendations:</h2> <ul> <li> <article> <h2><a href="#">Related article title</a></h2> <p>Article description</p> </article> </li> <!-- List of recommended articles continues --> </ul> </aside> </aside>
If you have a sidebar that has multiple sections, don’t nest <aside> elements inside of <aside> elements like in the example above. Instead, make the sidebar a single <aside> and then use <section> (or another appropriate sectioning element) to create the different sections.
<!-- Do this instead --> <aside aria-label="Side bar"> <section> <h2>Share</h2> <ul> <!-- List of social media links --> </ul> </section> <section> <h2>Recommended articles:</h2> <ul> <li> <article> <h2><a href="#">Related article title</a></h2> <p>Article description</p> </article> </li> <!-- List of recommended articles continues --> </ul> </section> </aside>
Article is like "Block"; Section is like "Element"
<section> and <article> are easy to get confused with one another. If you are familiar with "Block Element Modifier" (BEM) syntax, then an easy way to think of the difference between the two is that an <article> is a bit like the "B" (or "Block") in BEM. It is a container that stores self-contained content that still makes sense when placed in a different context. Individual tweets on Twitter and each list item on a search results page would be considered <article> elements.
<section> is like the "E" (or "Element") in BEM. It is a sub-section that requires context from its parent sectioning element to make sense. <section> is a generic catch-all sectioning element that you use when it doesn’t make sense to use the other sectioning elements. So, if in doubt, go with <section>.
Note that if something is styled as a "Block" in BEM, that doesn't automatically mean that it is an <article> element. Same goes for BEM "Elements" and <section> elements. The element of something should be based on the meaning of the content, not how the content looks.
Comments sections
Something that may surprise people is that individual comments on a blog post are also considered articles, even though they are in reply to the main blog post. The <article> element wrapping around the main blog post should also wrap around the comments section though. This is to represent that the comments go with the main article.
<article> <h1>I am an awesome blog post!</h1> <p>I am some body text content.</p> <section> <h2>Comments</h2> <ul> <li> <article> <h2>Username</h2> <p>This is the comment body text.</p> <footer> <p> Meta data like post date makes sense in either the header or the footer. </p> </footer> </article> </li> </ul> </section> </article>
Don’t swap <div> for <section>
Just because we have these fancy sectioning elements now, it doesn’t mean that the good old <div> element has lost all of its usefulness. <div> has no semantic meaning, so it is quite useful whenever we are altering the HTML purely for the sake of styling purposes.
Let’s say that we have a blog post contained inside an <article> element that we need to wrap in something for the sake of styling purposes.
<!-- I need a wrapper element --> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article>
Reaching for the <section> element in this circumstance is not the right thing to do.
<!-- Do not do this --> <section class="wrapper"> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article> </section>
Though <section> is technically a generic element, <div> is the far more appropriate option in this circumstance. This new wrapping container is not meant to have any semantic meaning behind it and that is exactly what <div> is designed to be used for.
<!-- Use a <div> if the element is only used for styling purposes --> <div class="wrapper"> <article> <h1>I am a blog post</h1> <p>I am some content</p> </article> </div>
Another way to remember this: if you can’t think of a meaningful heading to apply to a <section>, then it probably shouldn’t be a <section>.
Headers and footers
Although they don’t necessarily need to, sectioning elements may contain a single <header> and a single <footer> with the header being at the top of the section and the footer being at the bottom.
Sectioning elements can be nested inside one another as many times as is needed based on the content.
The header and footer in a sectioning element can also contain sectioning elements.
The one major restriction around nesting sectioning elements is that headers and footers cannot be nested inside other headers and footers.
Nesting headers and footers inside one another is not allowed.
What goes inside headers?
Headers are used for introductory content. Appropriate things to include in <header> elements include (but are not limited to):
The heading element (<h1>-<h6>)
An introductory paragraph or statement.
A profile picture
A logo
A search form
Primary navigation
Author’s name
Post/updated date
Meta data
Social media links
What goes inside footers?
Footer elements primarily hold things like meta data and minor supporting content. Appropriate things to include in <footer> elements include (but are not limited to):
Copyright information
Legalities
Footnotes
Low priority site navigation
Author’s name
Post/updated date
Meta data
Social media links
You will notice that there is some cross over between the header and the footer in terms of content that is appropriate to both. This is mostly because meta-type content fits well in either element. It mainly comes down to the design that you are trying to achieve. <header> elements do tend to signify that the content inside of them is of greater importance than the content inside of a <footer> element though.
Sectioning elements and the document outline algorithm
An important thing to know about these sectioning elements is that they are all supposed to feature a <h#> element inside of them (or be labeled in some other way, but more on that later). This is primarily for the sake of something called the document outline algorithm. This is an algorithm that uses sectioning elements to help determine what level a heading (<h#>) should be without having to rely exclusively on the number that the developer has provided. So, have you ever wondered whether or not it’s okay to have more than one <h1> on a page? This is meant to make that a non-issue (but hold on for a sec, because there is more to the story).
<!-- No Document outline algorithm --> <article> <h1>Primary heading</h1> <h2>Secondary heading</h2> <p>Some text.</p> <h3>Tertiary heading</h3> <p>Some text.</p> </article>
<!-- With document outline algorithm --> <article> <h1>Primary heading</h1> <!-- Recognized as <h1> --> <!-- sectioning element sets new heading level context --> <section> <h1>Secondary heading</h1> <!-- Recognized as <h2> --> <p>Some text.</p> <h2>Tertiary heading</h2> <!-- Recognized as <h3> --> <p>Some text.</p> </section> </article>
There is a lot more to learn about the document outline algorithm. I’ll stop here though because...
No browser supports the document outline algorithm
There is not a single browser that supports this method of creating a heading structure. This is a shame. It would make building accessible websites much easier if we didn’t have to worry so much about using the correct heading level all the time.
As far as I’m aware, there are two main reasons why no browser has implemented the algorithm. One is that browser vendors are afraid of breaking the heading structure of sites that have used sectioning elements incorrectly. The other reason is that the current document outline algorithm spec is difficult to implement and no browser vendor has been willing to put the time into implementing it yet.
In reference to the first reason, there is a long discussion about incorporating a new <h> element instead of using the <h1> element to tell browsers to use the document outline algorithm. I was in favor of this new <h> element idea until I realized that an attribute on the <html> element or adding a <meta> tag to the <head> would work even better as a means of telling browsers it was safe to use the algorithm. It is also better for headings to fall back to a <h1> in unsupported browsers than falling back to a <span>.
If you would like to play around with this <h> concept though, there is a plugin called hfill. It allows you to nest <hx> headings inside sectioning elements to create the document outline without having to worry about heading levels so much. There is a demo available for you to try it out. The major flaw in this plugin though is that the only way to increment heading levels is by nesting sectioning elements inside one another. There is no <h1>-is-greater-than-<h2> dynamic in this plugin which is the main reason I fell out of love with this <h> element idea. This lack of heading hierarchy would make CMS rich text editors far too difficult for clients to use.
As for the issue around implementation difficulty, work is being done to produce a simplified spec that browser vendors are more likely to adopt. The document outline algorithm has been in the HTML specifications for years. Hopefully this simplified spec will allow the algorithm to become a reality.
Although the algorithm is not supported anywhere yet, we can still build with the algorithm in mind. If we build with it in mind, then we gain the following benefits:
We future-proof our sites in case the algorithm ever does get implemented.
We can significantly improve the user experience for screen reader users.
We potentially improve search engine optimization (SEO) due to search engines being able to better understand the site’s content.
We can create a better user experience for users by allowing them to use native browser features that make use of sectioning elements, like Reader Mode.
Sectioning content
Take a look at this mock-up layout I put together and think about how you might split it up into sections.
This is how I would split the layout up into sectioning elements (only the solid lines represent sectioning elements).
In terms of HTML markup, it looks like this:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
The <main> element
There is a very important semantic element that I used in the markup above that I haven’t covered yet and that is the <main> element. The <main> element represents the primary content of the page. It is not supposed to feature any side bars or navigation elements in it. You also must not have more than one <main> element on the page unless all other <main> elements on the page have a hidden attribute applied to them (this is for the sake of SPAs).
The <main> element is not a sectioning element. This means that it doesn’t help contribute to the document outline algorithm and it can’t feature a <header> or <footer> element as a direct child. It is a landmark element though so screen reader users are able to navigate to it quite easily.
I’m not 100% sure if using <article> in the <main> element like I have done above is necessary. Semantically, it does make sense. The main content is self-contained, thus justifying use of the <article> element in this way. From a document outline algorithm perspective, the <article> element also helps with the document structure.
From a usability point of view, it feels a bit unnecessary and the document outline algorithm doesn’t even work anywhere at the moment. I’m going to continue using it throughout my examples but I would be interested to know what other people think about this in the comments section.
You need to label your sections. Here are three methods.
I am going to be saying the word "label" a lot throughout this article. Keep in mind that I am not talking about the <label> element. The <label> element is not used to label sectioning elements.
Sectioning elements require labels so that screen reader users are able to quickly identify what content they can find inside that particular section of the site. I consider using sectioning elements without providing associated section labels as an accessibility fail, unless it is the only one of its type on the page. It is also recommended that the exact same label text not be used on multiple sectioning elements (or heading elements). This makes each section more recognizable to screen reader users which helps them navigate the site more easily.
There are three ways to label a sectioning element. In the following examples, I refer to "transport" and "portability" as a way of explaining how easy it is to save the section into a component and use that component multiple times in multiple different contexts.
I also provide lists of positives and negatives in the examples as well. In these lists, I assume that you want the section label to be readable by screen readers but hidden from sighted users.
Method 1: Add an aria-label attribute
This is the quickest and easiest way to label a sectioning element.
<section aria-label="Label for this section"> <p>Content for this section</p> </section>
#The aria-label translation issue
The main draw back of aria-label (at the time of writing) is that most browsers are unable to translate these values for users who speak a different language than you. The developers at Google recently fixed this bug in Chrome, however this is still a problem for every other browser.
If your website has a large international audience or you know that many of your users do not speak your language, you should probably avoid using this attribute until all browsers support the translation of this property. If you don’t have those sorts of users, it’s pretty safe to assume that the non-sighted users viewing your site are able to understand your language — well enough to be able to navigate your site, anyway.
If you need more convincing, let's say your site has very few international users. That means your users generally come from the same country as you. If they come from the same country then they are likely to speak the same language as you, so there is already a fairly small percentage of your users that don’t understand the native language of your site. Now take into account that aria-label only affects screen reader users. That is now only a fraction of an already small percentage of your users who will experience the issue. And now consider that Chrome (by far the most popular browser in the world) now supports translation of the aria-label attribute. The user has to also not be using an up to date version of Chrome as their browser for the translation issue to be a problem. If you factor all of that together, it is highly probable that you may not have any users who are both able to perceive the aria-label attributes and are incapable of comprehending what they say. This makes me feel like the bad multi-lingual support in aria-label isn’t really worth worrying that much about unless you have a large international audience or you have many users that you know do not speak your language.
#Positives
Super quick and easy to implement.
Doesn’t affect heading structure.
Makes components easy to transport.
Is invisible to sighted users.
#Negatives
Not translated into other languages in non-Chrome browsers (at time of writing).
Often not supported by page structure analysis tools.
Confusion can arise from not knowing what level other headings inside the section should be at.
Method 2: Add a <h#> element to it
By <h#> I mean <h1>, <h2>, <h3>,<h4>,<h5>, or <h6> depending on what makes sense. Adding a heading to a sectioning element is a quick way to label it.
#Heading placement
The heading can be placed either directly in the sectioning element, like this:
<section> <h1>Heading</h1> <p>content</p> </section>
...or placed inside the <header> element:
<section> <header> <h1>Heading</h1> <p>I'm a byline</p> </header> <p>Content</p> </section>
You can also place as many <div> wrapper elements between the sectioning element and the heading as you want.
<!-- This is perfectly fine --> <section> <div> <header> <div> <h1>Heading</h1> <p>I'm a byline</p> </div> </header> <p>Content</p> </div> </section>
#Only one heading of the highest level per sectioning element
There should really only be one heading of the highest level in a sectioning element. The spec says that when there are multiple top level headings or headings of a higher level than the first, the browser is supposed to close the previous sectioning element and start a new one of the same type.
The first element of heading content in an element of sectioning content represents the heading for that explicit section. Subsequent headings of equal or higher rank start new implied subsections that are part of the previous section’s parent section. Subsequent headings of lower rank start new implied subsections that are part of the previous one. In both cases, the element represents the heading of the implied section.
—HTML 5.3, Headings and Sections
In reality, the browser uses the first heading as the section label but these implied sections are never created. It just announces the heading as is when it encounters it. It’s not earth-shatteringly bad but it is somewhat confusing.
<!-- Avoid this: --> <section> <h2>Heading level two labeling a section</h2> <p>Content</p> <!-- Don't use same level or higher headings as the one labeling the section --> <h2>This is also a heading level two</h2> <p>Content</p> </section> <!-- Do this instead: --> <div> <section> <h2>Heading level two labeling a section</h2> <p>Content</p> </section> <section> <h2>Heading level two labeling a different section</h2> <p>Content</p> </section> </div>
#The heading always comes first
If a sectioning element has a <h#> element, that top level heading should always be the very first piece of content inside that sectioning element. Failing to do so counts as an accessibility fail.
If you find yourself needing to place content before your heading (like an image, for example), you can use Flexbox to rearrange the visual order. This will allow it to look like the image comes before the heading but in the markup the heading comes before the image. There is a bug in IE that will sometimes cause text to not wrap in a flex-direction: column; element. You can work around this issue by applying a max-width to the flex-child element.
<!-- Don't do this --> <section> <img src="image.jpg" alt="Don't place content or images before the heading" /> <h2>Headings should always come first</h2> <p>Place regular content after the heading</p> </section> <!-- Do this instead --> <section class="example"> <h2>Headings should always come first</h2> <img src="image.jpg" alt="Don't place content or images before the heading" /> <p>Place regular content after the heading</p> </section> <style> .example { display: flex; flex-direction: column; } .example img { order: -1; } </style>
Note that rearranging the visual order to satisfy WCAG Guideline 1.3.2: Meaningful Sequence can conflict directly with WCAG Guideline 2.4.3: Focus Order. For example, if that image is a link to an article and the heading you are placing it above is also a link to the article, placing the heading first breaks the focus order. Placing the image first breaks the meaningful sequence.
In situations like this where these two guidelines conflict with one another, my opinion is that the 1.3.2: Meaningful Sequence guideline is the more important guideline to follow if you aren’t able to resolve the conflict in some way. Failing focus order leads to the user suffering a moment of discomfort as they are tabbing through the content and focus is sent to an unexpected location. Failing to follow a meaningful sequence leads to a confused user unsure of the relationship between different bits of content.
#Making visually hidden section labels out of headings
Headings are visible to sighted users by default. This makes them super useful if you want the heading to be visible. A lot of the time, we don’t want the label for our sectioning element to be visible though. In order to stop our sighted users from seeing the label, we need to use some CSS.
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <section> <h1 class="visually-hidden">Heading</h1> <p>content</p> </section>
#Headings are well-supported by structure analysis tools
Headings also have a huge advantage for developers in that any page structure analysis tool that you can find will have support for them. This makes heading structures easy to test and debug. The other two section labeling methods have very poor support in testing tools. Not even the official W3C Validator service supports the alternatives at the moment. I posted an issue to have this fixed — please consider helping to fix the issue if you are good at coding in Java.
#Positives
Quick to implement.
Reliably appears in page structure analysis tools making it easy to test and debug.
All browsers will translate the text into other languages.
No confusion over what level other headings inside the section should be.
#Negatives
Affects document heading structure.
Need to ensure that the heading is at the correct level before use.
Visible to the user by default.
Requires CSS to hide the heading from visual users.
Can make components less portable due to heading structure requirements.
Method 3: Use an aria-labelledby attribute
This is what it looks like to create a hidden section label using aria-labelledby.
<section aria-labelledby="unique-id"> <div hidden id="unique-id">Label for this section</div> <p>Content for this section</p> </section>
#Labels can be hidden without CSS
Note that I used the hidden attribute in the example to hide the div rather than a visually-hidden CSS class. aria-labelledby is able to read out text that is normally hidden from screen reader users. This adds the bonus effect of preventing the text from being read out twice by the screen reader. Don’t use the aria-hidden attribute though. Screen readers will not find the label text. Well, NVDA couldn’t find the label text when I tested it. I’m not sure about other screen readers.
#Major portability issue
aria-labelledby is the most difficult to use out of all the section labeling methods. The main aspect that makes it difficult to use is that the aria-labelledby attribute works off IDs. Things always get more complicated whenever IDs are involved. This is due to web pages only being allowed to have a single instance of an ID on the page at any one time. This makes component portability difficult.
Due to this portability issue, I would really only recommend this option if you need to support a multi-lingual audience and don’t want to mess around with the heading structure.
#No need to place the label near the sectioning element
You don’t need to place the element with the label text inside or near the section element that it labels. The text for the label can be placed in a completely different location to the sectioning element. This is thanks to the ID linking the two elements together. I’m not necessarily saying that it is a good idea to do this, but it is a feature of aria-labelledby that you should be aware of.
<div hidden id="unique-id">Label for this section</div> <!-- 1,000 lines of other HTML --> <section aria-labelledby="unique-id"> <p>Content for this section</p> </section>
#Turn non-heading elements into section labels
There is one other key reason you may want to use aria-labelledby. If you have a visible non-heading element on the page that you want to use as the label for a section, aria-labelledby is perfect for this. A <legend> element inside a <fieldset> is a common use case for this. This doesn’t mean that you have to wrap fieldsets in sectioning elements. I’m just pointing it out in case you spot a need for it.
<section aria-labelledby="section_label"> <fieldset> <legend id="section_label"> I am both the fieldset legend and the section label </legend> <!-- Form fields go here --> </fieldset> </section>
#Positives
All browsers will translate the text into other languages.
Can assign a non-heading element as the section label.
Text for the label does not need to be placed near the section it is labeling.
#Negatives
Requires the use of IDs to work.
Difficult to transport.
It can potentially be difficult to track down where the text for the label is stored in your source code.
Text is visible by default unless a hidden attribute is used.
Text might get read out twice by some screen readers if the text is not hidden.
Confusion can arise from not knowing what level other headings inside the section should be at.
Only use one method at a time
Don’t use a <h#>, an aria-label and/or an aria-labelledby attribute at the same time on the same sectioning element. Only every use one labeling method at a time for each sectioning element. Using multiple methods is super confusing and leads to the label being overwritten. It’s a bit like declaring the same property twice in CSS. I wasn’t sure how a screen reader would actually handle this so I created the most ridiculous <section> ever and ran it through NVDA.
<!-- Don't do this --> <section aria-label="Is this the section label?" aria-labelledby="is_this_the_label"> <h1>Or is this the section label?</h1> <p id="is_this_the_label">Only ever use one at a time.</p> </section>
This is the order of priority that NVDA gave to the various labeling methods from strongest to weakest:
aria-labelledby
aria-label
<h#>
Adding section labels to our example layout
For a long time, I used headings as the only means of labeling sections. The poor multi-lingual support provided by aria-label scared me; and aria-labelledby was far too cumbersome to be my primary labeling method. We run into a bit of an issue though if we use only headings to label sections. I’ll show you what I mean.
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <h2 class="visually-hidden">Primary</h2> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <h2 class="visually-hidden">Secondary</h2> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <h2 class="visually-hidden">Sidebar</h2> <section> <h3>Share</h3> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h3>Recommended</h3> <ul> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
If we look at our heading structure now, it will look like this (italics = visually hidden; bold = visible):
li.no-list-dot::before { display: none; }
<h2> Primary [nav]
<h2> Secondary [nav]
<h1> Main article heading
<h2> Article secondary heading
<h2> Sidebar
<h3> Share
<h3> Recommended
<h4> Related article
<h4> Related article
Notice that our <h1> heading isn’t at the top of the list? It really doesn’t feel right having two <h2> headings above the <h1> heading.
This form of heading structure is actually allowed by the W3C so it doesn’t count as an accessibility fail. I still think that this is a pretty bad UX for screen reader users though. It is not a logical progression from <h1> to <h2>. It makes the most sense if the first heading you encounter on the page is a <h1> then progress into <h2> then <h3> and so on.
Making Heading 1 be the first heading
For a very long time, I thought the absolute best way to handle this conundrum was to make the <h1> visually hidden and have it be the very first piece of content on the page. The thing that everyone thinks is the <h1> actually becomes a <h2>.
This is what that sort of structure looks like in practice:
<style> .visually-hidden { position: absolute; opacity: 0; pointer-events: none; } </style> <!-- Don't do this --> <body> <header> <h1 class="visually-hidden">Main article heading</h1> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav> <h2 class="visually-hidden">Primary</h2> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav> <h2 class="visually-hidden">Secondary</h2> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h2><span class="visually-hidden">Body:</span> Main article heading</h2> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h3>Article secondary heading</h3> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside> <h2 class="visually-hidden">Sidebar</h2> <section> <h3>Share</h3> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h3>Recommended</h3> <ul> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> <li> <article> <h4><a href="#">Related article</a></h4> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Now we have a document outline that looks like this (italics = visually hidden; bold = visible):
<h1> Main article heading
<h2> Primary [nav]
<h2> Secondary [nav]
<h2> Body: Main article heading
<h3> Article secondary heading
<h2> Sidebar
<h3> Share
<h3> Recommended
<h4> Related article
<h4> Related article
This mostly feels right. The <h1> is at the top and it all flows down perfectly with the <h2> elements representing major page sections and the <h3> elements representing sub sections. The main awkward bit is that the actual <h1> and the thing that everyone thinks is a <h1> are essentially duplicates of one another.
It wasn’t until I wrote up the first version of this article, had it nearly published, then had it thrown out the window, that I started to think differently. I talked with two accessibility consultants about the issue. They both agreed that, though this is a clever technical solution to the problem, it detracts from the experience of the very people that it is trying to help.
The issue is that when every other website in the world places the <h1> heading at the top of the main content area, that is what screen reader users come to expect. When your site is the special snowflake that does things differently, it confuses screen reader users and it takes them some time to figure out how your heading structure is supposed to work.
So, with that in mind, I’ve settled on a new method for handling the labeling of sectioning elements. Basically, any time I would have used a visually hidden heading, I would use an aria-label attribute now instead. If the site has a large non-native speaking audience, I would use aria-labelledby instead of aria-label.
Concerns with the simplified outline algorithm spec
If the simplified outline algorithm is approved in its current state, we will actually need to start structuring our sites like the visually hidden <h1> example anyway (just replace the <h2>, <h3> and <h4> elements with <h1> elements).
The original spec aimed to create the outline through the labeling of sectioning elements. This new spec is clearly aimed at trying to create the outline purely through heading levels. The algorithm basically calculates the heading level based on the number of ancestor sectioning elements a heading has plus the heading’s base heading level value. It's a bit more nuanced than that in the spec, but that is the general idea of how it works in simple terms.
The simplified algorithm currently makes no mention of aria-label or aria-labelledby. This means that those attributes will not help contribute to the document outline that the simplified algorithm generates. With a lack of aria-label support, this would mean labeling a sectioning element with aria-label could easily lead to skipped heading levels deeper in the tree.
<!-- Simplified algorithm skipped heading levels issue --> <body> <main> <h1>Primary heading for the page</h1> <!-- interpreted as <h1> --> <p>This is some content</p> </main> <!-- sectioning elements increase heading levels --> <aside aria-label="Side bar"> <!-- aria-label does not contribute --> <section> <h1>Share</h1> <!-- interpreted as <h3> --> <ul> <!-- list of social media links --> </ul> </section> <section> <h1>Recommended articles:</h1> <!-- interpreted as <h3> --> <ul> <!-- list of recommended articles --> </ul> </section> </aside> </body>
The simplified spec also considers it invalid to:
not have a heading level of 1 at the root of the document (which is problematic if you are placing the main body content inside an <article> element); and
not have a heading level of 1 be the first heading in a document (which, for the most part, is okay, unless you need to use a heading in the site header or in a left side bar).
It does, however, allow for there to be more than one level 1 heading at the root of the document, which I find very odd and bad for accessibility (though my concern about this seems to have been ignored).
I have voiced the issues I have with the spec and proposed possible solutions in the GitHub discussion.
For the moment, it is still best to use aria-label and/or aria-labelledby attributes instead of visually hidden headings to label sectioning elements. It isn’t worth diminishing the experience of our present day users for the sake of a spec that hasn’t even been finalized or accepted yet.
Using aria on the example layout sectioning elements
Using aria-label
This is what the HTML structure looks like if we use aria-label attributes to label the sectioning elements:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav aria-label="Primary"> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-label="site"> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav aria-label="Secondary"> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside aria-label="Sidebar"> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Here is the layout in CodePen in case you want to have a play around with it (sorry mobile users, it's not mobile friendly):
See the Pen Mock up page layout v2 (sections article) by Daniel Tonon (@daniel-tonon) on CodePen.
Using aria-labelledby
But let’s assume that you have a huge international audience that speaks all sorts of languages. In that case, it is better to use the aria-labelledby attribute. Here is what that would look like:
<body> <header> <a href="/" title="Go to home page"> <img src="logo.png" alt="Site logo"> </a> <nav aria-labelledby="primary-nav-label"> <div id="primary-nav-label" hidden>Primary</div> <ul> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> <li><a href="#">Primary nav</a></li> </ul> </nav> <form role="search" aria-labelledby="search-label"> <div id="search-label" hidden>Site</div> <label> <span>Search</span> <input type="search"/> </label> <button type="submit">Submit</button> </form> </header> <nav aria-labelledby="secondary-nav-label"> <div id="secondary-nav-label" hidden>Secondary</div> <ul> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> <li><a href="#">Secondary nav</a></li> </ul> </nav> <main> <article> <h1>Main article heading</h1> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p> <h2>Article secondary heading</h2> <p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p> <p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p> </article> </main> <aside aria-labelledby="sidebar-label"> <div id="sidebar-label" hidden>Sidebar</div> <section> <h2>Share</h2> <ul> <li><a href="#">Facebook</a></li> <li><a href="#">Twitter</a></li> <li><a href="#">Email</a></li> </ul> </section> <section> <h2>Recommended</h2> <ul> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> <li> <article> <h3><a href="#">Related article</a></h3> <p>Article description</p> </article> </li> </ul> </section> </aside> <footer> <ul> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> <li><a href="#">Footer link</a></li> </ul> </footer> </body>
Results of using aria
The heading structure for the site at this point looks like this:
<h1> Main article heading
<h2> Article secondary heading
<h2> Share
<h2> Recommended
<h3> Related article
<h3> Related article
The document outline (assuming that the original outline algorithm is implemented) looks like this:
<body> Document
<nav> Primary
<nav> Secondary
<article> Main article heading
<section (implied)> Article secondary heading
<aside> Sidebar
<section> Share
<section> Recommended
<article> Related article
<article> Related article
You might be thinking that the document outline looks a bit bare. Shouldn’t things like the header and footer and search be announced in there as well? Keep in mind that this is just the explicit stuff. We get a lot of implicit information provided to the user for free by using correct HTML elements in a good structure. This is a simplified version of how a screen reader user might experience the site:
[Text used in the <title> element]
Banner landmark
Link, site logo [(on focus) "go to home page"]
"Primary" navigation landmark
[List of navigation links]
"Site" search landmark
"Secondary" navigation landmark
[List of navigation links]
Main landmark
"Main article heading" article landmark, heading level 1
[Content]
Heading level 2, "Article secondary heading"
[Content]
"Sidebar" complimentary landmark
"Share" region landmark, heading level 2
[List of share links]
"Recommended" region landmark, heading level 2
List with 2 items
Item, "Related article" article landmark, heading level 3
[Content]
Item, "Related article" article landmark, heading level 3
[Content]
Content info landmark
[List of footer links]
As you can see, the site structure becomes quite clear and understandable to screen reader users when you factor in all of the extra implicit information that you get from using a good HTML structure
So, even though no browser supports the document outline algorithm, it is still worth putting some effort into thinking about the outline. Screen readers still tell users what type of section something is, where sections start and (sometimes) end (depends on the screen reader), and what the section label is. This means that your efforts to make a good document structure do not go to waste.
This type of structure comes with multiple benefits:
The page is 100% compatible with the document outline algorithm, future proofing it in-case the algorithm is ever implemented in a real browser.
The heading structure is completely logical.
Screen reader users navigating via headings can quickly jump to important information.
Screen reader users navigating via landmarks have lots of useful landmarks to move about the page.
Screen reader users are able to quickly understand what each section contains without having to read any of the content inside of them.
Content is grouped into semantic sections, so screen reader users do not get confused when leaving one section and entering another.
Search engines are able to better understand what information each section holds, which could potentially improve SEO.
Sighted users can take advantage of native browser features like Reader Mode.
What happens when you need h7?
There is one more sticking point when it comes to labeling sectioning elements that I haven’t addressed yet. Let’s say you have somehow managed to use up all six native heading levels and are now stuck needing one more. What do you do?
You could use the aria-labelledby technique if it is just for the sake of labeling a section. Let’s say that you really want this heading to appear in the heading structure though, or maybe you just want to avoid using IDs as much as possible. Whatever the reason, you need an <h7> element but <h7> doesn’t exist.
This is when the aria-level attribute comes to the rescue. The aria-level attribute will define what the heading level should be for elements that have role="heading" applied to them. This is how the W3C recommend creating a <h7> element:
<div role="heading" aria-level="7">This is a valid heading level 7 element</div>
Not all screen readers support this syntax. I know that JAWS treats these like <h2> elements rather than <h7> elements. If you know of any screen readers that this doesn’t work in, please report the bug to the screen reader developer and also leave a comment down below.
When I need to reach for an <h7>, I’ll often use the implied role="heading" from an <h6> element instead. The aria-level attribute will override the implicit "6" level of the <h6> element. This isn’t exactly endorsed by the W3C though. It is cleaner and will allow the heading to still appear in document outline and heading structure testing tools (though they will typically appear as <h6> or <h2> level headings, not as <h7> level headings).
<h6 aria-level="7">This is also a valid heading level 7 element</h6>
By using aria-level, you now have access to an infinite number of heading levels!
Does your site have a good structure?
Now that you know how to do a proper HTML structure, are you able to apply what you have learned to your website?
I found a pretty good browser extension called "Headings Map" that is available for both Chrome and Firefox. This extension will allow you to easily see both a flat heading structure representation of your site (i.e. how all browsers currently read the heading structure) and what the document structure looks like in a browser that supports the document outline algorithm (i.e. how a theoretical future browser that supports the outline algorithm would present the site structure). The HTML5 Outline view needs to be enabled in the settings menu first. This is to prevent users from being fooled into thinking that they are able to use the outline algorithm in production sites.
Headings Map does not currently support the aria-label and aria-labelledby attributes on sectioning elements in the HTML5 outline tab. I have been talking with the developer and he is working on fixing this issue. If you know of a good document outline testing tool that already takes aria-label and aria-labelledby into account, please share a link to it in the comments.
Once you have a good document structure testing tool, check that both the heading structure and the document outline display a logical order with no missing headings or missing section labels anywhere.
Download and use a screen reader
The best way to test the implied semantics that you get from using correct HTML is to download an actual screen reader and try navigating your site with it. NVDA is one of the most used screen readers used by real screen reader users. It’s also free!
Be aware that the default settings for NVDA are optimized for usage by blind users. These default settings can drive sighted users insane. To enjoy your time using NVDA, perform the following steps (steps are based on a Windows set up, I don't have a Mac):
Download NVDA and install it
Create a shortcut to NVDA in your task bar (You will be opening and closing it regularly while testing)
Open NVDA from the task bar
Find NVDA in your system tray
Right click the tray icon > "preferences" > "settings"
Select "mouse" in the left panel
Deselect "Enable mouse tracking" (You can now move your mouse without NVDA screaming at you)
Press "OK"
Right click the tray icon > "Tools" > "Speech Viewer" (You can now see a log of everything NVDA says, don't rely purely on this when testing though)
In the Speech Viewer, check the "Show Speech Viewer on Startup" checkbox (It will open the Speech Viewer when you open NVDA)
Familiarize yourself with some of the keyboard controls
To close NVDA, Right click the tray icon > "Exit" > "OK"
NVDA currently doesn't support <article> and <section> elements. There is an issue on GitHub for supporting <article> elements. When I began writing this article <section> elements were already supported. Support for <section> seems to have dropped for some reason. This means NVDA should be fixed. It doesn't mean you should stop using the correct semantics in your HTML.
Build your website with the document outline in mind then test the semantics with Headings Map and NVDA (or another screen reader). If you do, you will make your screen reader users very happy. You might even make the search engines happier too. 😊
Special thanks to Eric Bailey (accessibility adviser for CSS Tricks) and Kevin Galvin (a principal consultant at me 2 accessibility) for their advice around the usability issues of using a visually hidden <h1> element at the top of the page and suggesting aria-label as an alternative to using visually hidden headings.
The post How to Section Your HTML appeared first on CSS-Tricks.
How to Section Your HTML published first on https://deskbysnafu.tumblr.com/
0 notes