问题描述
我知道使用占位符文本作为标签不是很容易，但是从技术上讲，它是否符合WCAG 2？我找不到任何明确的内容，但我想知道如果从法律角度更仔细地阅读该标准，是否会发现其中的一些内容。
解决方法
真正的简短答案：仅仅满足所有成功标准还不够
2.5.3: Label in Name声明占位符可以作为“名称标签”的候选对象。
这并不意味着它将满足3.3.2 Labels or Instructions。
尽管占位符文本为许多用户提供了有价值的指导，但占位符文本不能替代标签。屏幕阅读器等辅助技术不会将占位符文本视为标签。
SC 3.3.2 does require a visible label（文本或图标，例如带有放大镜按钮的搜索表单 ）或说明。
on the WCAG github还讨论了有关“隐藏标签”的问题。
如果您反对不“隐藏”一个占位符，那么一旦填写该字段就不再是这种情况了，例如在使用屏幕放大镜时可能很难理解其含义）。它还受浏览器自动填充功能的约束。
因此，实际上，使用占位符不会违反WCAG，这还不够：仅当占位符不可见时，2.5.3 SC才适用；而除非使用了指令或其他技术，否则3.3.2将失败。
,首先阅读：这并不是建议您使用占位符而不是标签，而是在WCAG指导下关于占位符是否足够的思想试验。如果您确实使用了占位符而不是标签，那么您的站点将无法访问，因为我之前在数百个答案中都已经提到过。如果您因歧视而被起诉，我怀疑此答案是否会对您有所帮助（也不应如此）。
要清楚-请使用可见且正确关联的标签！ / endRant hehe。
简短答案
仅占位符且标签不超过确实符合WCAG 2.1，但谁知道所有冲突的准则。
您会认为，成千上万个单词中会有一行显示“使用标签”或“仅占位符的输入将使此条件失败”，但我找不到它。
以下内容可能很难理解，因为我阅读了所有可以找到确切答案的页面，因此可能有些脱节，抱歉！
问题
好的，所以让我们假设我们不在乎可用性，而是关注关于WCAG 2.1的“法律法规”，因为这是一个有趣的问题。
现在，让我们假设我们纯粹是在谈论标准<inputs>和<textarea>来简化操作（因为复选框，selects等都肯定需要标签），而且它们是唯一接受的标签占位符仍然有价值（我认为？！）。
什么规则适用于可能相关的输入和标签？
这里相关的是1.1.1 Non-text Context，1.3.1 Info and Relationships，2.4.6 Headings and Labels，3.3.2 labels or instructions和4.1.2 Name,Role,Value。后来我发现了2.5.3: Label in Name。
1.1.1
控件，输入：如果非文本内容是控件或接受用户输入，则其名称描述其用途。
现在从技术上讲，标准<input>并没有涵盖其中，该标准更多地用于图像作为按钮，自定义控件等。
但是，如果我们假设可以拉伸1.1.1来覆盖<input>，那么该标准中是否有任何内容意味着我们不能使用占位符（或必须相关标签）。
如果您阅读了整个页面，那么在表单控件上没有需要特别提及的<label>元素。
结果：到目前为止，两种方法都没有答案
1.3.1
检查1.3.1-尽管它提到标签，但它没有在任何地方特别提到<label>元素。它还指出，是应该以编程方式确定关系还是以文本形式表示关系，这是一个“判断电话”。
在某些情况下，可能需要判断是否应该以编程方式确定关系或以文本形式显示关系。但是，当技术支持程序关系时，强烈建议通过程序确定信息和关系，而不要用文字描述。
结果：无论哪种方式都没有确定的答案
2.4.6
现在，我们可以打折2.4.6标题和标签，因为标题和标签仅要求描述性标签，而没有专门说明必须提供标签。
结果：不相关
3.3.2
现在我们在谈论，“标签或说明”必须给我们一些具体答案，对吧？
此成功标准不要求正确标记，标识或与各自的控件关联的标签或说明。
那很烦人，在这里没有答案！
实际上，它使我们回到了1.3.1，我们已经对其进行了研究，并确定没有明确的答案。
它还将我们指向4.1.2-也许我们会对这个标准有所了解？
结果：不相关
4.1.2
对，一定是这样！至少从正确的轨道开始！
对于所有用户界面组件（包括但不限于：脚本生成的表单元素，链接和组件），名称和角色可以通过编程确定；
现在，此操作的关键部分是“以编程方式确定”。
好的，"programmatically determined"的定义是什么？
由软件根据作者提供的数据确定，该数据是由不同的用户代理（包括辅助技术）可以提取信息并将其以不同的方式呈现给用户的方式
好了，现在我们可能正在尝试一些事情。不同的用户代理和辅助技术可以提取占位符信息吗？这是一种有效的标记技术吗？
结果：仍然没有确定的答案
这是我们最终找到相关WCAG建议的地方（或者是吗？）
成功标准2.5.3：名称中的标签
2.5.3 label in name必须是我们要找的确认信息。
请注意，输入字段内的占位符文本不被视为提供标签的适当方法。 HTML5规范规定，placeholder属性不应用作的替代。 但是，值得注意的是，该HTML5语句中的“标签”位于代码括号中并指向标签元素。出于名称成功标准中此标签的目的，在这样的程序设计意义上，只是在视觉上接近组件的文本字符串。因此，在附近没有其他任何文本字符串（如上列表中所述）的情况下，如果输入包含占位符文本，则此类文本可能是“名称中的标签”的候选项。通过可访问的名称计算（稍后讨论），以及从实际的意义上讲（如果没有另外提供可见标签），语音输入用户很可能会尝试使用占位符文本值作为与输入进行交互的方式。
在所有这些杂乱无章的事情中（正如您所知，我讨厌阅读那些繁琐而又不清楚的指南。）
“如果输入包含占位符文本，则该文本可能是“名称中的标签”的候选。”
这样，我们将为控件指定一个“以编程方式确定”的名称。 （请参阅下一个标题）
以上段落的旁注： “请注意，输入字段内的占位符文本不被视为提供标签的适当方法。”会让您相信占位符不能用作标签。
它还指出，“ HTML5规范规定不应将占位符属性用作<label>的替代。”
现在对我来说，这足以说服您使用标签。
然而，WCAG再次指出，网页应为“有效的HTML”（在SC 4.1.1 - Parsing下）。
带有占位符的<input>是有效的HTML吗？很好的答案（根据W3C validator是肯定的！以下是有效的HTML！
<html lang="en">
<head>
<title>test</title>
</head>
<body>
<form>
<input placeholder="test"/>
</form>
</body>
</html>
所以，如果它是有效的，我会说这在技术上是可以接受的。
可访问名称计算
我在那儿走了近一秒钟。我说的是placeholder属性是可访问名称计算的有效候选者。
Here it is,the accessible name computation for an <input>。相关的点是第4点：
- 否则，请使用控件的占位符属性。
好，因此placeholder对于“以编程方式可确定的”有效，但是标签是否必须可见？
有趣的是，您不必为1.1.1、1.3.1和4.1.2拥有可见标签，因此我们不能在需要实际标签时使用该参数。
取自H44: Using label elements to associate text labels with form controls
此技术（将标签与输入相关联）足以满足成功标准1.1.1、1.3.1和4.1.2 标签元素是否可见。使用CSS隐藏。
话要说的是下句话。...
但是，对于成功标准3.3.2，label元素必须可见，因为它为需要帮助了解该字段目的的所有用户提供了帮助。
但是在3.3.2中，尽管它必须是可见的，但不必正确地进行标记（请记住，我很久以前就说过！）。
因此，在WCAG中可以找到所有相关信息，结果仍然是模糊的，但话虽如此，我确实为您得出结论！
结论
在WCAG中没有任何地方明确地声明不能将占位符用作标签。
WCAG also states that a title can be used to label an input，这比占位符还差。
我可能在某个地方错过了一个可以将所有内容绑在一起的关键句子，但是根据我的阅读，我相信（非常令人惊讶！），根据WCAG 2.1，只有<input>上的占位符。
很明显，正如我多次说过的那样，请勿在输入上仅使用放置器，因为许多用户无法使用它（患有焦虑症或学习困难的人实际上讨厌带有占位符标签的输入，因为标签在键入时会消失，因此他们无法检查是否在不删除所有内容的情况下填写了正确的字段），某些屏幕阅读器和浏览器组合无法使用等。