In-page tabs
Summary
In-page tabs are used heavily in the RAFT example of DM-BI applications. When viewing content types like cost objects (projects made up of budgets, time, and people) it is essential to provide views of each sub-content type while minimizing clicks for users. 
Code
Example (in use, with an interaction, in context)
Related patterns
Navigation
Problem (business, user, technical)
Users need access to a lot of information at once. This information is made up of very different content types. We needed to keep the content within its parent project, allowing users to see the project hierarchy (using the left navigation and breadcrumbs) and valuable metadata relevant to all tabs.
Solution
The landing page or default tab is a summary of the most used and most relevant information. Users navigate across tabs to access less used content without having to leave the page.
Rationale (other things we tried)
We considered placing all the information on a single long scrolling page, but the tables were deemed too long for efficient reading, and users would lose the context of the breadcrumb, page titles, etc as they scrolled down.
Accessibility

In-page tabs

1. Summary
   1. In-page tabs are used heavily in the RAFT example of DM-BI applications. When viewing tabular data (like cost objects, projects made up of budgets, time, and people) it is essential to provide views of each content and sub-content type while minimizing clicks for users. 
2. Code
3. Example (in use, with an interaction, in context)
4. Related patterns
   1. Navigation, in-line
5. Problem (business, user, technical)
   1. Users need access to a lot of information at once. This information is made up of very different content types. We need to keep the content within its parent view, allowing users to see a complete hierarchy and valuable metadata relevant to all tabs.
6. Solution
   1. Typically, landing pages serve as summaries, showing the default tab of the most used and most relevant information. Users navigate across tabs to access less used views of content without having to leave the page.
7. Rationale (other things we tried)
   1. We considered placing all the information on a single long scrolling page, but the tables were deemed too long for efficient reading, and users would lose the context of the breadcrumb, page titles, and metadata as they scrolled down.
8. Accessibility