Semantic UI 不是真正的语义化框架，其类名仅提供样式而非语义；语义必须由原生 HTML 标签（如 、、）和属性（如 for/id、type、name）承担，CSS 类仅负责视觉呈现。

Semantic UI 不是“语义化 CSS 框架”的理想实现，它只是用语义化类名包装了 UI 组件，实际 HTML 结构仍需开发者自己保证语义正确性。

为什么 ui button 不等于语义化

Semantic UI 的类名（如 ui primary button）描述的是视觉角色和交互意图，而非 HTML 元素本身的语义。浏览器和读屏器只认 、

• 提交 —— 无语义，键盘不可聚焦，AT（辅助技术）无法识别为可操作控件
• 提交 —— 正确：原生 提供语义 + ui button 提供样式
• 所有交互元素必须用对应语义化标签包裹： 用于跳转， 用于触发行为， 包裹导航，
  表示页眉区域

ui container 和

的关系

ui container 是 Semantic UI 提供的居中、带内边距的布局容器，但它不替代语义化结构标签。用错会导致文档大纲断裂或 SEO 削弱。

• 错误写法：

  首页

  —— 无语义，
  缺失上下文
• 推荐写法：

  
    
  
      
  首页
    
    
  欢迎来到我们的网站。
  

• class="ui container" 可叠加在

  

  、
  、 等语义标签上，二者职责分离：HTML 标签负责结构语义，CSS 类负责视觉呈现

表单控件必须配 ，ui form 不自动帮你做

ui form 只是一组样式规则，不会生成 或绑定 for/id。跳过这步会直接导致表单不可访问。

• 错误：

• 正确：

  
    
      邮箱
      
    
  

• 注意：type="email" 比 type="text" 更具语义；name 属性对表单提交必要；placeholder 不能替代

真正决定语义的是你写的 HTML 标签和属性，不是 Semantic UI 的类名。框架能帮你快速出样式，但语义责任始终在开发者手上——尤其当 被用来展示一篇新闻时，记得外面套个 ，里面标题用

，时间用 。这些细节不难，但漏掉一个，语义就断了。