Semantically correct html for react accordion component - html

I currently have a functional react accordion component that has the following semantics:
<AccordionWrapper(div)>
<AccordionTab(div)>
<AccordionHeader(div)></AccordionHeader(/div)>
<AccordionContent(div)></AccordionContent(/div)>
<AccordionTab(/div)>
</AccordionWrapper(/div)>
I have read a few articles suggesting that it is best practice to use a button html element for the accordion header. I have read this gitHub post. This post also link to a example by which shows a button being used.
Another example I found was from accessible-accordion-pattern it also shows the use of a button and div approach. What justification is there for using a button over a div for an accordion container?
Another article I found was from Carnegie Museums of Pittsburgh and their accessibility. The example also shows a use of a button for their accordion header. This also leads me onto another question. In their example they use ul and li html tag. Is this the correct approach? I haven't managed to find another example which looks like this.
I'm currently trying to increase accessibility for my accordion component but unsure on the semantics. Also below I have added the aria tags I am using. Is the below sufficient or should I be using any additional aria tags?
<AccordionWrapper>
<AccordionTab role='tab'>
<AccordionHeader aria-expanded={...} tabIndex={...}>
heading name here
</AccordionHeader>
<AccordionContent aria-hidden={...}>
Any content I choose here
</AccordionContent>
<AccordionTab>
</AccordionWrapper>
How does my semantics I am using above stand for my goal to increase my accessibility, should I be using button for accordion header and also incorporate ul and li or is it best practice doing something completely different? Any simple examples displayed like above would be greatly appreciated.

I would recommend going to the source and use the accordion pattern on the WAI-ARIA Authoring Practices 1.1 page.
It sounds like all the other sites you referenced are using the same pattern on the aformentioned W3C page, which is great. Consistency across applications is the purpose of having the pattern.
You shouldn't be useing role="tab" on an accordion. That's for the Tabs pattern.

Related

Buttons in nav instead of anchor? [duplicate]

This question already has an answer here:
Why are buttons discouraged from navigation?
(1 answer)
Closed last year.
I've been reading up on web accessibility and read that anchor tags should only be used when the user will be taken to another URL without JavaScript. But buttons should be used whenever some other behavior should happen, such as opening a modal.
So I'm wondering if it's okay or expected to have both buttons and anchors in a nav. Something like this:
<nav>
Home Page
About Page
<button>Sign Up</button>
</nav>
Say in this situation the signup button launches a modal or does some other behavior that doesn't take the user to a different URL. Is it okay to have both in the nav? I'm not concerned about styling, I'll make these look consistent, but I'm wondering what's the most correct way to handle something like this?
From an accessibility perspective, using both links and buttons is the semantically correct way to go. The links take you to another page (or somewhere else on the current page) and buttons perform an action. A screen reader user will understand when they hear "link" or "button" in the same <nav> that different actions will happen.
As mentioned in the previous comments, yes, it is completely fine to use both inside your navigation.
If you really want to you can use <a> elements for all, but for the buttons you would include the role="button" attribute which is semantically equivalent to using <button>.
<nav>
Home Page
About Page
<a role="button">Sign Up</a>
</nav>
Yes it's totally fine to use either buttons, anchors or even div inside the navbar however you want you can do it. You just need to be comfortable using css and styling which you say you are. Then you should have no problem. Does that answer your question?
Any flow content elements are allowed in a nav tag, and that includes buttons.

Grid/Box Header Menu Dreamweaver

I'm an HTML/CSS beginner. I've made my first homepage without too much difficulty but I want to add some style to my header.
Could someone point me in the direction of a tutorial or basics of how to build a grid for my links or a starting point? I've been looking for one and typing up grid or table results in tutorials to create actual tables so I've not found anything appropriate to what I want to do yet.
From what I can gather if I can separate each list item and give it a border my idea is achievable but I'm struggling with positioning.
I don't know if Dreamweaver supports it, but i'd wrap the menu in a <div> that uses the CSS display: table-row attribute. Then i'd wrap each menu item in a separate <div> that uses the CSS display: table-cell attribute.
There is plenty of resources out there, I would reccommend checking around CSS Tricks and Site Point.
Here is one from sitepoint
Here is one from CSSnewbie
Here is one from CSS-Tricks

HTML CSS Tab Menus

I am working with the Google Engine for a class, and I had a question about css tabbed menus. I found a tutorial for tabbed menus, here is the link to that one if it matters:
http://www.marcofolio.net/css/sweet_tabbed_navigation_using_css3.html
I was wondering if anyone knew of a way to make it so that it didn't have to reload the page every time I click a link in the menu. Basically have it already have the info in memory and change just the text, or only refresh a specific part of the page. I have no idea what types of stuff you might need, but I basically copied that code exactly, and used the app engine and template inheritance to get the different page info. Let me know if you need other info. Thanks in advance.
WWaldo
I can suggest at least two possibilities using JavaScript; you could either target the links in your CSS menu items towards:
Altering the content (e.g., the value of the src attribute) of a main iframe element (for example), or revealing/replacing preloaded content into/out of div element(s); and/or,
Trigger an AJAX call to a server to determine an update, and update the contents of the required components (e.g., div) dynamically.
The difference is pre-loading all the page content first (1) as opposed to accessing it dynamically on command (2). If you don't have control over a server to implement AJAX in suggestion (2), then (1) will suffice, but at the cost of offloading the work (and downloads) to the client.
Both approaches will require dynamic update of page contents using JavaScript. The 'net is littered with examples of this; check out this one, for instance.
It is actually quite easy to make a tabbed menu in HTML, with CSS, javascript is not needed for my design. I did this example in about 1/2 an hour.
Here are some screenshots of my example. (I Censored My Name Out Of The URL, And I Cropped Them)
All you do is make 3 boxes, With links to other webpages in them. It can look the same in all the pages. It is recommended to make rounded corners.
<div id="Tab1">Tab Numbah One </div><div id="Tab2">Tab Numbah Two </div><div id="Tab3">Tab Numbah Three </div>
Go into your external CSS sheet, make them all float left, and on the same line, make it look pretty, and you NEED a border of some sort.
Then make an overriding style in each of your pages. Make the bottom border non-existent, so it looks like the tabs of a binder. I changed the color, so when you were on that page, it looked a bit better. Note, I indent my CSS very unusually.
Page 1
#Tab1 {
border-bottom:none;
background-color:white;
}
Page 2
#Tab2 {
border-bottom:none;
background-color:white;
}
Page 3
#Tab1 {
border-bottom:none;
background-color:white;
}

Using the <legend> tag for input

So I've got a form, who's content will change based on a dropdown list of different reports. So the question is, how horrible would it be to include a select box as the legend tag for the fieldset?
I know that technically it works, and semantically it makes sense (the actual text of the legend tag, the selected value is a caption of the contents of the fieldset). But I can't help but feel dirty doing it.
If it's semantically correct and the page HMTL validates then I don't see why not.
However, I'm sure there are other UI solutions to your problem. Perhaps using jQuery UI's tabs or something similar. http://jqueryui.com/demos/tabs/

What's the best way to go from a Photoshop mockup to semantic HTML and CSS?

I generally use a manual process:
Look at the page, figure out the semantic elements, and build the HTML
Slice up the images I think I'll need
Start writing CSS
Tweak and repeat different steps as necessary
Got a better approach, or a tool?
I have a fairly natural way of coding. The key is to treat the page like a document or an article. If you think of it like this the following becomes logically clear:
The page title is a top level heading
Whether you make the site title or actual page title the h1 is up to you - personally I'd make About Us the h1 rather than Stack Overflow.
The navigation is a table of contents, and thus an ordered list - you may as well use an ol over a ul.
Section headers are h2, sections within those sections are h3s etc. Stack them up.
Use blockquotes and quotes where possible. Don't just surround it with ".
Don't use b and i. Use strong and em. This is because HTML is structural rather than presentational markup. Strong and emphasis tags should be used where you'd put emphasis on the word.
<label> your form elements.
Use <acronym>s and <abbr>s where possible, but only in the first instance.
The easiest: always, always give your images some alternate text.
There's lots of HTML tags you could use that you probably haven't - address for postal addresses, screen code output. Have a look at HTML Dog for some, it's my favourite reference.
That's just a few pointers, I'm sure I could think of more.
Oh, and if you want a challenge write your XHTML first, then write the CSS. When CSS-ing you aren't allowed to touch the HTML. It's actually harder than you think (but I've found it's made me quicker).
Well, when I build a website I tend to try and forget about the design completely while writing the HTML. I do this so I won't end up with any design-specific markup and so I can focus on the semantic meaning of the elements.
Some pointers how to markup things:
menu - use the UL (unordered list) element, since that's exactly what a menu is. an unordered list of choices. example:
<ul id="menu">
<li id="home">Home</li>
<li id="about">About</li>
</ul>
if you'd like an horizontal menu you could do this:
#menu li {
display: block;
float: left;
}
Logo - use a H1 (heading) element for the logo instead of an image.Example:
<div id="header">
<h1>My website</h1>
</div>
And the CSS (same technique can be applied to the menu above if you would like a menu with graphical items):
#header h1 {
display: block;
text-indent: -9999em;
width: 200px;
height: 100px;
background: transparent url(images/logo.png) no-repeat;
}
IDs and classes - use IDs to identify elements that you only have one instance of. Use class for identifying elements that you got several instances of.
Use a textual browser (for instance, lynx). If it makes sense to navigate in this way, you've done good when it comes to accessibility.
I hope this helps :)
I essentially do the same thing Jon does, but here are a few other ideas:
Use Guides in Photoshop (and lock to them). Figure out all of your dimensions for each box/ region ahead of time.
Collect all of your dimensions and color hex values into an info file (I use a txt file) that you can easily reference. This will reduce your alt-tab tax and selecting colors in Photoshop multiple times.
After all my Guides are in place, I slice out the entire website into my images folder, starting with photos and grouped elements, and ending with the various background tiles/images, should they exist. (Tip: Use ctrl-click on the layer preview to select that layer's content).
Notes on using Photoshop:
Use Guides or the Grid.
Use the Notes feature for any pertinent information
Always use Layer Groups for similar elements. We need to be able to turn entire regions off in one click. Put all 'header' content in one Layer Group.
Always name your layers.
You can put each page template in one PSD file and use nested Layer Groups to organize them. This way we don't have to setup all of our guides and notes for each page template on a site.
No shortcuts :) but everybody works slightly differently.
This tutorial that popped up in my feedreader yesterday shows the process from start to finish and might help people who have never done it before but as you are an old hand it's just about streamlining your own methods.
EDIT:
The listapart link certainly is more automated for 'flat' designs where both imageready and fireworks have had pretty good support from day one and it's got better and more semantic with every release but if you have a more complex design it's the twiddly bits that make the design what it is and these have to be done by hand.
I just thought it was worth pointing out that in addition to the excellent advice you've had so far I'd recommend getting a printed version of the design, using a red pen to mark up all the block elements on the design you think you can spot and sitting down with the designer for half an hour and talking through how they envisioned their design working for the use cases that don't fit the static design.
What happens when more text is put in the navigation?
Is this width fixed or fluid?
Is this content pane to the right fixed height or fluid? If it's fluid why did you put a background on it that can't be repeated?
You have a border extending down the page that breaks two otherwise connected elements. Visually it makes sense, but semantically I not can't just use an li to house both those elements. What do you think is more important?
It'll also help you spot potential problems that you might otherwise not have realised were going to be issues until your elbow deep in css.
Not only does it make your job easier after a few times doing it your designer will get a much stronger sense of what is involved in marking up their work - some designers have real trouble comprehending why something they think looks visually very simple will take a few days of css tweaking to make work.
Some of the designers i know, usually uses Illustrator to make the design elements.
This page shows how to do it a little more automated.
Also, get to know the "Layer Comps" feature. I use this for changing button states.
Create layer comps for normal, hover, and active.
In each of these, set up the effects/color overlays and visible layers which belong with that state.
Save for web: go to a different folder for each state, unless it's easier to rename each slice (otherwise your hover button slices will overwrite your regular slices).